Rickard has expressed concerns that the new metadata structure is
not dynamic enough. I'm not totally clear on his objection, but I thought
I'd review what we've done so far, and then hopefully he can jump in and
fill in the gap.
Right now, the metadata is split into "plugins" where each plugin
holds a number of properties for each bean, field, method, and container.
There are a small number of fixed fields (the name of a field or bean and
the name and parameter types for a method) used as identifiers. This is
the way one plugin indicates that its metadata should be associated with a
bean that may have some metadata loaded from another plugin - it uses the
name of the bean, or whatever.
All the properties are loaded as a plugin is loaded. So if the
JAWS plugin defines a DB table name, and it is loaded, then every bean has
a DB table name. If it's not loaded, no bean has a DB table name.
The structure is not *totally* dynamic - it's doesn't magically
know which plugins to load or unload based on the current set of data.
Rather, it depends on a structure where you manually tell it which plugin
to use to read a particular configuration file, etc. So to give an
example, in the main container factory, you'd load the ejb-jar.xml and
jboss.xml using the EJB and JBoss plugins, and then if the beans used JAWS
you'd load (or let the JAWSPersistanceManager load) the jaws.xml using the
JAWS plugin.
The only problem I really see here is that the availabile plugins
are stored statically, so once you've loaded the JAWS plugin, every bean
will have the JAWS properties. They would presumably never be used if the
bean doesn't use JAWS, but it is a bit of wasted space. And, this
eliminates the possibility of mutually exclusive plugins, which use
properties with the same name, etc. Perhaps it would be more appropriate
to identify plugins on a "ServerMetaData" basis, which is essentially on a
JAR by JAR basis.
And the more I think about it, I suppose "ServerMetaData" really
should be "ApplicationMetaData" since it refers to the group of beans
loaded by one particular set of configuration files - normally, the beans
in one JAR. But that's not quite the right name either. Any suggestions?
Rickard, would the change to non-static identification of
applicable plugins resolve your issue, or is it something else?
Thanks,
Aaron
