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:
Then when ejb3-deployers.jar is dropped in, it installs the necessary components into MC. Likewise each component is a "drop-in" installation.
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?
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.