Hi!
Aaron Mulder wrote:
>
> 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.
This is similar to the current EJX plugins.
> 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 similar to the current EJX plugins.
> 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.
This is not how the current EJX plugins work. The global settings are
contained within the container configuration, and additional settings
are provided with the separate JAWS plugin. What would need to change in
the current EJX plugin is to add the JAWS settings dynamically as an
aspect of the jBoss settings.
> 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.
This *is* done in the current EJX plugin.
> Rather, it depends on a structure where you manually tell it which plugin
> to use to read a particular configuration file, etc.
So the key question is: how do you know which plugins to use??
> 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.
You stepped over the most important step here. The "if the beans used
JAWS". This should not be done manually. When the structure is loaded
the JAWS settings plugin should automatically be added as an aspect of
the EJB *that uses JAWS*. The other beans should *not* have these
aspects added. This is doable by changing the current code.
> 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.
Yes, this is one of the main problems I have with the new metadata
structure.
> 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.
This is also not good. You have a flat view of all settings for a bean,
which can give overlaps. This is not good, and it is a rather
unnecessary restriction.
> Perhaps it would be more appropriate
> to identify plugins on a "ServerMetaData" basis, which is essentially on a
> JAR by JAR basis.
The plugins should be on a bean by bean basis. If a bean needs some
particular aspect, add it to that bean.
> 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?
The main issue is that I don't really see how the metadata you submitted
is a big gain over what is currently available.
Could you enumerate briefly the main features of the new metadata
structures, and what the main goals are. Thanks.
regards,
Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
