The MBeanServer of a J2EE Application Server
During JavaPolis, I've had the chance to discuss with Eamonn, and he
brought to the discussion that right now there is no standard way to access the MBeanServer that is normally instantiated by a J2EE application server.
Take a servlet or a session EJB, they can only try to call
and guess which one of the MBeanServers contained in the List is the application server's one.
As an example, the above call returns one MBeanServer (the Application Server's) in J2SE 1.4, but returns two in J2SE 5.0 (the platform MBeanServer and the Application Server's).
We were discussing that 'something' can be registered in the naming service, say
under java:comp/env/jmx/whatever.
That 'something' can be something new, but that would require new JMX classes (or new J2EE classes): not ideal, since they will be available only in the future, and not widely adopted for a longer time.
Another solution we discussed was to register in JNDI a JMXConnector, already defined by JSR 160 and present in J2SE 5.
A J2EE specification (most likely JSR 77) may reserve a protocol, say 'j2ee', for such a JMXConnector. JMXServiceURLs would look like service:jmx:j2ee://host/jndi/whatever.
Specifying a new protocol allows the application server to have full control on the implementation, for example to filter method calls (e.g. to avoid to mess with the Application Server's MBeans).
The binding to the naming service can be defined in a new element in the J2EE deployment
descriptor, and the usual J2EE stuff can be applied with regards to security (I don't think any transaction is needed, nor any thread control, etc.).
A client application can lookup the JMXConnector, and then connect (possibly providing credentials), and then use the standard API to register, query, unregister, invoke methods on MBeans, if the application server allows that.
Using standardized classes (JSR 160 classes), standardizing the lookup mechanism (defining a java:comp/env/jmx context) and reserving the JMXServiceURL protocol are the first steps I think, but they're enough, probably, to provide a first implementation by application servers.
A maintenance release of JSR 77 can decide/standardize more, if needed.
However, application servers like Geronimo may already try to implement this solution and provide good feedback on pros and cons of this solution.
brought to the discussion that right now there is no standard way to access the MBeanServer that is normally instantiated by a J2EE application server.
Take a servlet or a session EJB, they can only try to call
List mbeanServers = MBeanServer.findMBeanServer(null);
and guess which one of the MBeanServers contained in the List is the application server's one.
As an example, the above call returns one MBeanServer (the Application Server's) in J2SE 1.4, but returns two in J2SE 5.0 (the platform MBeanServer and the Application Server's).
We were discussing that 'something' can be registered in the naming service, say
under java:comp/env/jmx/whatever.
That 'something' can be something new, but that would require new JMX classes (or new J2EE classes): not ideal, since they will be available only in the future, and not widely adopted for a longer time.
Another solution we discussed was to register in JNDI a JMXConnector, already defined by JSR 160 and present in J2SE 5.
A J2EE specification (most likely JSR 77) may reserve a protocol, say 'j2ee', for such a JMXConnector. JMXServiceURLs would look like service:jmx:j2ee://host/jndi/whatever.
Specifying a new protocol allows the application server to have full control on the implementation, for example to filter method calls (e.g. to avoid to mess with the Application Server's MBeans).
The binding to the naming service can be defined in a new element in the J2EE deployment
descriptor, and the usual J2EE stuff can be applied with regards to security (I don't think any transaction is needed, nor any thread control, etc.).
A client application can lookup the JMXConnector, and then connect (possibly providing credentials), and then use the standard API to register, query, unregister, invoke methods on MBeans, if the application server allows that.
Using standardized classes (JSR 160 classes), standardizing the lookup mechanism (defining a java:comp/env/jmx context) and reserving the JMXServiceURL protocol are the first steps I think, but they're enough, probably, to provide a first implementation by application servers.
A maintenance release of JSR 77 can decide/standardize more, if needed.
However, application servers like Geronimo may already try to implement this solution and provide good feedback on pros and cons of this solution.
posted by Simon at
18:00
