ejb3-deployers-jboss-beans.xml core

[jaikiran]

While working on some of the integration points for ejb3-nointerface component, i noticed that the ejb3-deployers-jboss-beans.xml in "core" has MC beans from across various other components (like ejb3-deployers) on which "core" never even depends (not even transitively). For example, we have the:

<bean name="Ejb3MetadataProcessingDeployer"
 class="org.jboss.ejb3.deployers.Ejb3MetadataProcessingDeployer" />

The org.jboss.ejb3.deployers.Ejb3MetadataProcessingDeployer comes in from the ejb3-deployers component on which core has no dependency.

I am planning to move that bean definition out to a ejb3-blah-what-do-we-call-this-jboss-beans.xml in the ejb3-deployers component. This way, it will be more tied to the ejb3-deployers component and any changes to the bean internals, in a new version can be managed within this components.

Any thoughts around this? Although it doesn't directly affect backward compatibility (i.e. we still ship this bean, although in a new file and a different component) is there anything else that i should be concerned about while moving this?

P.S: This is just one example. There are many other MC bean configs in that file which probably need to be moved to their own components.

[alrubinger]

We're currently (well, everyone is ;) ) using one or two jboss-beans.xml files as a dumping grounds for all internal configs. It'd be great to split these up, per component, and hide them into a JAR assembly such that the user doesn't think they're for them to configure.

So jar -tvf ejb3-deployers.jar:

/META-INF/jboss-deployers-jboss-beans.xml
/org/jboss/ejb3/otherClasses

Then when ejb3-deployers.jar is dropped in, it installs the necessary components into MC. Likewise each component is a "drop-in" installation.

S,
ALR

[jaikiran]

That's actually a good point. I remember Scott/Bill too had similar thoughts about such files. I'll have to do some testing to see if the AS/MC picks up these files if they are in the jars and if it requires such jars to be present in some specific locations (i have a feeling that it will ignore these files if the jars are in common/lib).

However, the other side of this is - how does it affect the support team? They probably won't be able to provide quick workarounds/fixes in these files. And even extracting, then fixing the file and then adding back the file to the jar, isn't an option too when the jars are signed. Should we be thinking about this, probably the right way to fix/workaround the problem is rebuild the jar completely?

[wolfc]

The META-INF/*beans.xml files are only picked up when these are under deploy or deployers, not from lib.

Some components have and can do a standalone bean installation and these should contain a beans descriptor that those so.

For the overall there should be one beans descriptor (in AS integration module) that does the complete configuration of integration components (especially if we need components that are outside ejb3 land).

For backwards compatibility we only need to make sure that the complete ejb3 distribution is as such, not individual components.