mpriest
Jan 6th, 2006, 01:09 PM
Hi,
I have a question regarding the new setExposeManagedResourceClassLoader operation in MBeanExporter that was introduced in version 2.0 M1. The implementation of this functionality does not follow the recommended JMX approach of using the javax.management.loading.ClassLoaderRepositor for handling classloader issues.
Looking at the implementation using SpringModelMBean it appears that the setExposeManagedResourceClassLoader operation was added to handle classloading issues for spring beans loaded in a container such as a web container. The SpringModelMBean implementation switches the context classloader of the SpringModelMBean to that of the context classloader when the SpringMBean was created before invoking operations or accessing attributes. I assume this is so the Spring bean uses the context classloader that the developer is expecting - namely the one used in the rest of the deployed application. This might not be the case in a web container, such as Tomcat, that creates an MBean server without the classloaders assigned to its web applications in the ClassLoaderRepository.
In our application we use our own custom PrivateMLet classloaders and create our MBeans with them using this MBeanServer operation:
public ObjectInstance createMBean(String className,
ObjectName name,
ObjectName loaderName)
Before calling this method we register the MLets with the MBeanServer ClassLoaderRepository using the ObjectName referenced in "loaderName". This method of creating the MBean ensures that operations invoked and attributes retrieved on our MBean will use our MLet classloader as the context classloader.
I am not sure that the SpringMBean implementation will work for us or not yet. I suspect not because the MBeanServer in Sun's reference implementation (which we are using) is very picky about classloaders.
Why did you not choose to implement the setExposeManagedResourceClassLoader operation using the existing JMX ClassLoaderRepository mechanism? The Spring approach in this case is not the recommended JMX approach for using custom classloaders.
Thanks,
Mark
I have a question regarding the new setExposeManagedResourceClassLoader operation in MBeanExporter that was introduced in version 2.0 M1. The implementation of this functionality does not follow the recommended JMX approach of using the javax.management.loading.ClassLoaderRepositor for handling classloader issues.
Looking at the implementation using SpringModelMBean it appears that the setExposeManagedResourceClassLoader operation was added to handle classloading issues for spring beans loaded in a container such as a web container. The SpringModelMBean implementation switches the context classloader of the SpringModelMBean to that of the context classloader when the SpringMBean was created before invoking operations or accessing attributes. I assume this is so the Spring bean uses the context classloader that the developer is expecting - namely the one used in the rest of the deployed application. This might not be the case in a web container, such as Tomcat, that creates an MBean server without the classloaders assigned to its web applications in the ClassLoaderRepository.
In our application we use our own custom PrivateMLet classloaders and create our MBeans with them using this MBeanServer operation:
public ObjectInstance createMBean(String className,
ObjectName name,
ObjectName loaderName)
Before calling this method we register the MLets with the MBeanServer ClassLoaderRepository using the ObjectName referenced in "loaderName". This method of creating the MBean ensures that operations invoked and attributes retrieved on our MBean will use our MLet classloader as the context classloader.
I am not sure that the SpringMBean implementation will work for us or not yet. I suspect not because the MBeanServer in Sun's reference implementation (which we are using) is very picky about classloaders.
Why did you not choose to implement the setExposeManagedResourceClassLoader operation using the existing JMX ClassLoaderRepository mechanism? The Spring approach in this case is not the recommended JMX approach for using custom classloaders.
Thanks,
Mark