A common pattern is to have an attribute of type String containing the full class name of a class implementing some interface of yours that you instantiate in the mbean.
Just be carefull when loading the class:
If you want to have many of them, why not using an attribute of type String?
In any case, no need to change any dtds, whatsoever...
Cool. I will check it out. Editing the DTD was a last resort and not something I really wanted to do.
The plugins are not only classnames but also the class arguments. Basically I want to be able to instantiate classes using a specific constructor. All passed in through the -service.xml file.
Then you'll have a problem. I guess there are 3 solutions.
1) Make the plugins mbeans (or xmbeans) themselves, so you can create them using any constructor (the -service.xml syntax permits this). Then make the central mbean have a dependency list with their ObjectNames:
<mbean code="myBean" name="domain:name=x"> <depends-list optional-attribute-name="ObjectNameList"> <depends-list-element>domain:name=y</depends-list-element> <depends-list-element>domain:name=z</depends-list-element> </depends-list> </mbean>
This has the advantage of the plugins being manageable as well.
2) Have an attribute of type org.w3c.dom.Element that supports your own arbitrary format for specifying classes and constructors parameters. You'll then have to parce that dom Element and do whatever (instantiate and initialize the mbean. As an example see how the SubscriptionList attribute is parsed in class org.jboss.system.ListenerServiceMBeanSupport, or look at how org.jboss.system.ServiceConfiguration is implemented.
3) Wait a few months for the new JBoss MicroContainer that will let you do (1) but without actually the mbean requirement.
Sounds like I need a MagicBean!
The plugins could be MBeans as well and register with the Mbean using the plugins.
You would need a register/deregister fuction like this:
register( IPlugin p );
deregister( IPlugin p );
The plugin MBean would call these functions and pass itself.