Re: XInfo vs Spice metadata

On Mon, 2003-10-27 at 18:19, peter-4lf8KW9E9MLMqX/[email protected] wrote:
> Hi,
> 
> > I was just wondering what the motivation was to use attributes over the
> > .xinfo format you were using in phoenix.
> 
> The main reason for using attribute rather than .xinfo files is
> extensibility. In Phoenix we had multiple descriptors
> 
> .xinfo files: Contain "component model" metadata
> .mxinfo files: Contain jmx/management metadata
> 
> The problem was that we were constantly coming against the limitations of
> this. Everytime we needed more metadata we had to either alter the schema or
> add a new descriptor. Users also constantly wanted to extend the metadata
> for their own purposes but were not able to do so. We also ended up having
> several ugly hacks in various components due to this.
> 
> For example some of the Phoenix components that did things like expose the
> components as RMI/AltRMI/SOAP services had marker interface such as
> 
> interface Soapable {}
> 
> That interface was simply to represent the component as being capable of
> being exported via soap. Often we had ApplicationListeners (things that
> received events everytime a component was setup) that looked like
> 
> class SoapExporterListener
> {
>   public void blockAdded( BlockEvent event )
>   {
>      Object o = event.getObject();
>      if( o instanceof Soapable )
>      {
>         m_exporter.export( event.getName(), o );
>      }
>   }
> }
> 
> Now they would look like
> 
> class SoapExporterListener
> {
>   public void blockAdded( BlockEvent event )
>   {
>      Object o = event.getObject();
>      if( null != Attributes.getAttribute( o.getClass(), "soap.component" ) )
>      {
>         m_exporter.export( event.getName(), o );
>      }
>   }
> }
> 
> Not much I grant you but now we could add parameters to the metadata such as
> 
> class SoapExporterListener
> {
>   public void blockAdded( BlockEvent event )
>   {
>      Object o = event.getObject();
>      final Attribute attribute =
>          Attributes.getAttribute( o.getClass(), "soap.component" );
>      if( null != attribute )
>      {
>         final String displayString = attribute.getParameter(
> "displayString", "" );
>         final String impact = attribute.getParameter( "impact", "ACTION" );
>         m_exporter.export( event.getName(), o, displayString, impact );
>      }
>   }
> }
> 
> etc.
> 
> It also means users can add their own metadata with very little hassle.

Why can't you use both approaches? How often is the schema for your
components really changing? I just found the .xinfo format very readable
and could be easily unmarshalled to a nice object model.

You can always also provide the attributes mechanism so folks can add it
if they wish. I was more concerned with the component descriptors. So
the .xinfo is now gone?

> However the biggest advantage is that you can simply add more metadata as
> you need it. In my current project I make extensive use of transactions - if
> in the future I wanted to write a Loom extension that automatically managed
> these transactions I could just read the attributes in the "tx.*" namespace
> and not have to worry about loading a new descriptor or modifying an
> existing descriptor.
> 
> In the future I plan on adding support for remoting to Loom contain and also
> for wiring up event systems. However the new metadata for these features
> will not impact on any existing metadata and will be transparently supported
> without having to write new descriptor format and all that junk.
> 
> > Can you have a rich object
> > model with the attributes? By that I mean that I liked the .xinfo format
> > because you could really put whatever you wanted in there and unmarshall
> > the xml into a nice object model. Does using attributes allow this?
> 
> We still do this. Currently we unmarshall the attribute metadata into two
> "rich" object models. The ComponentInfo object (for component metadata) and
> the MBeanModelInfo object (for management metadata). I am sure that future
> features will also map into rich object models if it is demanded.

Ok, where are you doing that? Maybe I'll just lift that. I'm still
aiming for Loom/Plexus interop at the component level.

> > Is there really a difference in having an .xinfo descriptor along side
> > the component as opposed to having a class which containers attributes?

> only when there is multiple descriptors to consider or you want easy
> mechanisms for extensibility.
> 
> > It just seems to me like the representation available in the attributes
> > could be limiting.
> 
> Slightly limiting but nothing I have had serious problems with in my
> experience.
> 
> > Maybe I have this wrong but are you planning to replace the .xinfo file
> > with attributes or is this just to augment the information in .xinfo.
> 
> Already replaced ;)
> 
> > At
> > this point I don't honestly see the advantage of attributes over an xml
> > descriptor.
> 
> Maybe I have changed your mind ... or maybe not ;)

I'll take a peek. Really I don't care as this process I plan to hide
from users anyway so whether the generated information goes to an XML
file or class file is really moot.

> _______________________________________________
> jcontainer-interest mailing list
> jcontainer-interest-81qHHgoATdGxIXFVlbCvtR2eb7JE58TQ@public.gmane.org
> http://lists.codehaus.org/mailman/listinfo/jcontainer-interest
-- 
jvz.

Jason van Zyl
[email protected]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society