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]>
