Re: XInfo vs Spice metadata

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.

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.

> 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 ;)