Re: Problem with Tomcat 3.3.2-dev and classloader for JMX
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]
Re: Problem with Tomcat 3.3.2-dev and classloader for JMX
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 ). Hi Costin, hope you enjoy your vacations ;) Ok, I does the same, ie put mx4j and mx4j-tools in common but I've got a problem when trying to use mx4j http adaptor which require TRAX (ie xalan). And we couldn't use any xalan jar here since apps could want to use their own xalan isn't it ? I send a dummy example, where the jtc code for MDynamicBean was duplicated and moved in modules/config, ie next to MxInterceptor and sus allowing us to have mx4j/mx4j-tools in container (next to bundled xalan). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Problem with Tomcat 3.3.2-dev and classloader for JMX
Henri Gomez wrote: 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 ). Hi Costin, hope you enjoy your vacations ;) Ok, I does the same, ie put mx4j and mx4j-tools in common but I've got a problem when trying to use mx4j http adaptor which require TRAX (ie xalan). And we couldn't use any xalan jar here since apps could want to use their own xalan isn't it ? With JDK1.4 - this is not possible anyway ( unless reverse loader is used to load org.apache.xalan classes ). Just put xalan in common, it won't be worse :-) ( or use 1.4 ) The alternative is to put mx4j-tools in container and make sure the right class loader is used ( i.e. explicitely pass the loader when constructing the mbean - I think it is possible ). But I wouldn't waste time with that. I send a dummy example, where the jtc code for MDynamicBean was duplicated and moved in modules/config, ie next to MxInterceptor and sus allowing us to have mx4j/mx4j-tools in container (next to bundled xalan). -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Problem with Tomcat 3.3.2-dev and classloader for JMX
With JDK1.4 - this is not possible anyway ( unless reverse loader is used to load org.apache.xalan classes ). Interesting point here, will it be possible when using jdk 1.4 to use a specific xalan at least for webapp ? Just put xalan in common, it won't be worse :-) ( or use 1.4 ) So we'll have to put xalan/xerces in commons ? May be time to upgrade the build to xerces-j 2.1.0, xalan 2.4.0 and xml-commons 1.0 ? The alternative is to put mx4j-tools in container and make sure the right class loader is used ( i.e. explicitely pass the loader when constructing the mbean - I think it is possible ). But I wouldn't waste time with that. Ok, so you suggest to put jaxp + mx4j + mx4jtools in commons and warn users that their apps will have to use the commons JAXP, MX4J and MX4JTOOLS (since a webapp may also use mx4j for it's own purposes ?) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Problem with Tomcat 3.3.2-dev and classloader for JMX
Henri Gomez wrote: With JDK1.4 - this is not possible anyway ( unless reverse loader is used to load org.apache.xalan classes ). Interesting point here, will it be possible when using jdk 1.4 to use a specific xalan at least for webapp ? It is certainly possible to use a different xslt ( saxon, etc ) - using the normal jaxp discovery. It should be possible to use a different version of xalan - if a non-delegating class loader is used ( since org.apache.xalan is in rt.jar ). Just put xalan in common, it won't be worse :-) ( or use 1.4 ) So we'll have to put xalan/xerces in commons ? It's easier. May be time to upgrade the build to xerces-j 2.1.0, xalan 2.4.0 and xml-commons 1.0 ? One important note: if JDK1.4 is used, there is a whole issue with 'endorsed' system property. Cutpaste from catalina.sh is the best solution, however I had some problems loading jni code from java ( with jdk1.4, if the endorsed property was set). Very strange, I just worked around - but we may need to revisit. The alternative is to put mx4j-tools in container and make sure the right class loader is used ( i.e. explicitely pass the loader when constructing the mbean - I think it is possible ). But I wouldn't waste time with that. Ok, so you suggest to put jaxp + mx4j + mx4jtools in commons and warn users that their apps will have to use the commons JAXP, MX4J and MX4JTOOLS (since a webapp may also use mx4j for it's own purposes ?) If you just want to play with mx interceptor - that may be the best ( at least short-term ) solution. Right now there isn't very much support - we need to add more interesting info ( i.e. getters for status and config, etc - in various interceptors ). What I'm interested most is the jk-level components. I'll send some proposals this week - I have some ideas here. As soon as 4.1 is released I'll start some discussions on the new coyote hooks and the new 'notes', I have some interesting ideas. -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Problem with Tomcat 3.3.2-dev and classloader for JMX
I'm not sure if this mail ever arrived on list ? 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. I tried to put a copy of o.a.t.u.mx.DynamicProxy is o.a.t.m.c, near MxInterceptor, the classload disapears and I got the http connector when got the following error when adding a context ... PS: I attached the modified MxInterceptor, MxUtil (to prevent MxInterceptor load exception when no jmx jar is available in container) and the copy DynamicMBeanProxy. Just for your information (you'll see from commented code, that I spend interesting time with classloaders ;-[) 2002-09-20 21:58:30 - ContextManager: Tomcat configured and in stable state EmbededTomcat: exception initializing ContextManager java.lang.NoSuchMethodError at org.apache.tomcat.modules.config.MxInterceptor.addContext(MxInterceptor.java:126) at org.apache.tomcat.core.ContextManager.fireAddContext(ContextManager.java:613) at org.apache.tomcat.core.ContextManager.init(ContextManager.java:588) at org.apache.tomcat.startup.EmbededTomcat.initContextManager(EmbededTomcat.java:581) at org.apache.tomcat.startup.EmbededTomcat.execute1(EmbededTomcat.java:722) at org.apache.tomcat.startup.EmbededTomcat$1.run(EmbededTomcat.java:706) at org.apache.tomcat.util.compat.Jdk12Support$PrivilegedProxy.run(Jdk12Support.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.tomcat.util.compat.Jdk12Support.doPrivileged(Jdk12Support.java:99) at org.apache.tomcat.startup.EmbededTomcat.execute(EmbededTomcat.java:704) at java.lang.reflect.Method.invoke(Native Method) at org.apache.tomcat.util.IntrospectionUtils.execute(IntrospectionUtils.java:87) at org.apache.tomcat.startup.Main.execute(Main.java:313) at org.apache.tomcat.startup.Main.main(Main.java:140) Guessed home=C:\jakarta-tomcat-3.3.2 Exception: java.lang.reflect.InvocationTargetException java.lang.reflect.InvocationTargetException: org.apache.tomcat.core.TomcatException: EmbededTomcat.initContextManager at org.apache.tomcat.startup.EmbededTomcat.initContextManager(EmbededTomcat.java:587) at org.apache.tomcat.startup.EmbededTomcat.execute1(EmbededTomcat.java:722) at org.apache.tomcat.startup.EmbededTomcat$1.run(EmbededTomcat.java:706) at org.apache.tomcat.util.compat.Jdk12Support$PrivilegedProxy.run(Jdk12Support.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.tomcat.util.compat.Jdk12Support.doPrivileged(Jdk12Support.java:99) at org.apache.tomcat.startup.EmbededTomcat.execute(EmbededTomcat.java:704) at java.lang.reflect.Method.invoke(Native Method) at org.apache.tomcat.util.IntrospectionUtils.execute(IntrospectionUtils.java:87) at org.apache.tomcat.startup.Main.execute(Main.java:313) at org.apache.tomcat.startup.Main.main(Main.java:140) Root Exception: org.apache.tomcat.core.TomcatException: EmbededTomcat.initContextManager org.apache.tomcat.core.TomcatException: EmbededTomcat.initContextManager at org.apache.tomcat.startup.EmbededTomcat.initContextManager(EmbededTomcat.java:587) at org.apache.tomcat.startup.EmbededTomcat.execute1(EmbededTomcat.java:722) at org.apache.tomcat.startup.EmbededTomcat$1.run(EmbededTomcat.java:706) at org.apache.tomcat.util.compat.Jdk12Support$PrivilegedProxy.run(Jdk12Support.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.tomcat.util.compat.Jdk12Support.doPrivileged(Jdk12Support.java:99) at org.apache.tomcat.startup.EmbededTomcat.execute(EmbededTomcat.java:704) at java.lang.reflect.Method.invoke(Native Method) at org.apache.tomcat.util.IntrospectionUtils.execute(IntrospectionUtils.java:87) at org.apache.tomcat.startup.Main.execute(Main.java:313) at org.apache.tomcat.startup.Main.main(Main.java:140) /* $Id: MxInterceptor.java,v 1.5 2002/09/19 09:03:15 hgomez Exp $ * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source
Re: Problem with Tomcat 3.3.2-dev and classloader for JMX
- 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. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
