Julian Gosnell wrote:
> Scott M Stark wrote:
>>>
>>What algorithm have you come up with that allows for dynamic self configuring
>>code? I would love to take a look at that! Feel free to speak to your heart's
>>content on this issue as far as I'm concerned.
An example is from Jetty itself. Jetty creates MBeans to manage each HttpListener
that is added to a class. Now there can be many different implementations of a
HttpListener - SSL, JSSE, SASL, Socket, some are thread pools some may have thread
pools managed elsewhere.
The Jetty JMX support classes includes a ModelMBeanImpl class that has and
abstract defineManagedResource method which can be implemented to describe the
particular type of HttpListener that the MBean is managing. Extra attributes
may well be added. (And the ModelMBeanImpl class does a nifty search for
mbean resource bundlers to fetch internationalized meta data about them).
The type of a listener is determined at runtime, hence the attributes are.
The current Jetty HttpListener use inheritance to create the final attribute
mix, so it is not that dynamic - but nothing stops new HttpListener types being
so.
The point is that here is an MBean whose implementation object and hence final
set of attributes is not determined until runtime. IF this was going to
be a JBoss server (which in this case it is not), then I could simply add
a isJBossService method to the MBean.
More importantly at the moment, JBoss tries to call init() on this MBean. This
fails, but it would be perfectly valid for this MBean to have it's own init()
method.
So there is no known class or interface type that can be used to show that
this MBean is or is not a JBoss service.
The presence of an init() method is a dangerous but almost sufficient way
to go.
The addition of a isJBossService method is simple, clear and unambiguous.
The use of another configuration file to list which MBeans are JBoss objects
is workable, but would be a constant source of misconfiguration and confusion.
Use of object name patterns to identify JBoss MBeans is possible, but could
also be confusing. Plus in the case of Jetty, it's management MBeans are
named relative to it's root MBean, which is a JBoss service. This naming allows
associated MBeans to be identified, but should not indicate that they are
all JBoss services.
I think there are three test scenarious we must consider for any solution:
+ Adding a non-JBoss service MBean to a JBoss server - it should not have
init called no matter what it's signature is.
+ Adding a new JBoss service MBean that has been implemented is some
unknown way, but that wishes to be managed as a MBean. It should be able
to ask for this management via it's API without revealing details of
it implementation.
+ Adding JBoss service MBeans to another JMX framework. These modules will
be living in a target rich environment and need a method to locate and interoperate
with the other JBoss MBeans - communicating only via JMX.
cheers
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
