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