Bill Barker wrote: > > ----- Original Message ----- > From: "Henri Gomez" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, September 19, 2002 4:25 AM > Subject: Problem with Tomcat 3.3.2-dev and classloader for JMX > > >> I've got a problem in loading MX4J and it's http adaptator. >> >> I initially put mx4j and mx4j-tools in lib/container, >> next to crimson and xalan but at init time the ClassLoader >> didn't find mx4j/mx4j-tools there. >> >> When I moved mx4j and mx4j-tools to lib/common, both are >> found but http connector couldn't be loaded since it need >> crimson and xalan which are in lib/container. >> >> How could I update MxInterceptor to make use of lib/container >> CL and sus being able to put mx4j jars in lib/container ??? >> > > What needs to happen is to split the j-t-c tomcat-util.jar into two jars > (one for common and one for container/server). I haven't had the time to > inventory what is there and decide what should go in which jar. > > Putting mx4j in common opens a major problem, since you make every webapp > "trusted" that way. It's clear that o.a.t.u.mx needs to go in container. > It's the rest I'm not sure of.
Not sure I agree ( completely ). In theory, jmx is a 'system' API, and we can expect it to be in common. J2EE has it, catalina has it, etc. So we need to make sure it's security works and it is safe. I agree - it is much 'safer' to keep in in container/. But there are many cases where this is not possible. For my tests - I put mx4j and mx4j-tools in commons, I never got it to work with them in container ( the current version of mx4j may work - it had some classloaders problems or I didn't use it the right way ). Costin > >> >> >> >> >> -- >> To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> >> -- Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
