Larry Isaacs wrote: > Hi Henri, > > The basic problem is that o.a.t.u.mx.DynamicMBeanProxy.java > carries dependencies, which imposes requirements on the > classloader hierarchy for any class that uses it. In this > case the "jmx", "parser", and "tranform" jars would need > to move to lib/common where tomcat-util.jar lives. I would > be in favor of sacrificing code reuse to avoid these > restrictions. I think this would be a lot easier than > trying to implement classloader tricks. > > I think the best way of accomplishing this is to make > the JMX support an add-on module with its own local copy > of DynamicMBeanProxy. Then, there is no impact on > classloaders and enabling is simply dropping a war file > in the "modules" directory. > > A first pass implementation, derived from what you have > done, can be found here: > > <http://jakarta.apache.org/~larryi/JmxSupport.war> > > It contains the mx4j jars, so they aren't needed in > lib/container. If this approach is acceptable, I can > update the jakarta-tomcat build to include it. > > Note: You will need the recent TrustedLoader.java > update before add-ons will deploy successfully.
If this solution allow use of JMX without having to put jmx/jmx-tools and xerces/xalan in common/lib I'm +1. Also did it allow a webapp to use it's own JMX ? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
