gcj & JMX

Wed Feb 14 23:18:00 GMT 2007

On Wed, 2007年02月14日 at 18:14 +0000, Andrew Haley wrote:
> I've come across a bug (or just a difference) between mx4j and
> Classpath that prevents Tomcat's org.apache.catalina.core.StandardHost
> from being initialized correctly.
>>> org.apache.commons.modeler.Registry.registerComponent() 
>> calls 
>> getMBeanServer().registerMBean( mbean, oname)
>> with oname = javax.management.ObjectName@2aaab4e37e00
> {
> java.lang.String canonicalName = "Catalina:host=localhost,type=Host",
> java.lang.String propertiesString = "type=Host,host=localhost",
> boolean isDomainPattern = false,
> boolean isPropertyPattern = false,
> }
>>> with mx4j, the calling sequence is then
>> mx4j.server.MX4JMBeanServer.registerMBean(java.lang.Object, javax.management.ObjectName)javax.management.ObjectInstance
> at mx4j/server/MX4JMBeanServer.java:753
>> mx4j.server.MX4JMBeanServer.registerMBeanImpl(java.lang.Object, javax.management.ObjectName, boolean)javax.management.ObjectInstance
> at mx4j/server/MX4JMBeanServer.java:769
>> mx4j.server.MX4JMBeanServer.registerImpl(mx4j.server.MBeanMetaData, boolean)void
> at mx4j/server/MX4JMBeanServer.java:822
>> mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.registration(mx4j.server.MBeanMetaData, int)void
> at mx4j/server/interceptor/ContextClassLoaderMBeanServerInterceptor.java:159
>> mx4j.server.interceptor.DefaultMBeanServerInterceptor.registration(mx4j.server.MBeanMetaData, int)void
> at mx4j/server/interceptor/DefaultMBeanServerInterceptor.java:110
>> mx4j.server.interceptor.DefaultMBeanServerInterceptor.registration(mx4j.server.MBeanMetaData, int)void
> at mx4j/server/interceptor/DefaultMBeanServerInterceptor.java:110
>> mx4j.server.interceptor.SecurityMBeanServerInterceptor.registration(mx4j.server.MBeanMetaData, int)void
> at mx4j/server/interceptor/SecurityMBeanServerInterceptor.java:133
>> mx4j.server.interceptor.DefaultMBeanServerInterceptor.registration(mx4j.server.MBeanMetaData, int)void
> at mx4j/server/interceptor/DefaultMBeanServerInterceptor.java:110
>> mx4j.server.interceptor.InvokerMBeanServerInterceptor.registration(mx4j.server.MBeanMetaData, int)void
> at mx4j/server/interceptor/InvokerMBeanServerInterceptor.java:157
>> org.apache.commons.modeler.BaseModelMBean.preRegister(javax.management.MBeanServer, javax.management.ObjectName)javax.management.ObjectName 
> at org/apache/commons/modeler/BaseModelMBean.java:1397
>> org.apache.catalina.core.StandardHost.preRegister(javax.management.MBeanServer, javax.management.ObjectName)javax.management.ObjectName
> at org/apache/catalina/core/StandardHost.java:807
>> org.apache.catalina.core.ContainerBase.preRegister(javax.management.MBeanServer, javax.management.ObjectName)javax.management.ObjectName
> at org/apache/catalina/core/ContainerBase.java:1406
>>> With Classpath, none of this ever happens. Instead,
> gnu.javax.management.registerMBean(Object, ObjectName) does not call
> MBeanRegistration.preRegister() unless ObjectName == null.
>> So, the preRegister method is never called.
>> The spec for MBeanServer.registerMBean() says "If the object name
> given is null, the MBean must provide its own name by implementing the
> MBeanRegistration interface and returning the name from the
> preRegister method."
>> I suspect, however, that if the MBean is implements the
> MBeanRegistration interface we should call the preRegister method
> regardless.
>> I'm going to try it.
>> Andrew.

Sounds good to me; I hope this fixes the problem. Maybe I shouldn't
stick to the specs and just go with common sense in future... ;)
Thanks for spotting this,
Cheers,
-- 
Andrew :-)
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://gcc.gnu.org/pipermail/java/attachments/20070214/3e490912/attachment.sig>