Henri Gomez wrote: > Hi to all, > > If you tracked the discussion about MxInterceptor and it's > use in Tomcat 3.3.2-dev you should know that we have some > modification to Tomcat 3.3.2 jars layout to be able to > use MxInterceptor : > > 1) mx4j and mx4j-tools should goes in lib/common > > 2) mx4j-tools HTTP adaptor require TRAX (xalan), > so we should put in common/lib JAXP+XML PARSER+TRANSFORMER, > and as such could use : > > xerces-j2 2.1.0 > xalan-j2 2.4.0 > xml-commons-apis 1.0 > > Since these jars will be in lib/common, users won't be able > to use another one for it's own apps. > > 3) We'll have to remove JAXP/XML-PARSER for lib/container. > > > Thanks to give your opinion here. > > [+0] 1. Don't care about MBeans, or do want to be able to have > different XML apis for apps and container, so keep the > current situation.
I care about MBeans, but we can keep the current situation as stable and copy xerces, xalan, etc in common/ for mx experiments. > [ ] 2. MxInterceptor is really needed, ok to change the layout, > we'll warn users in Changelog / Readme It is needed - for experiments and to enahance the module. Right now it's not very usefull without ability to save and with the limited visibility ( i.e. very few info is available ). As we implement the proposed JNDI/JMX config ( for 5.0 - but will work with any tomcat in the same way ) - MxInterceptor will become essential ( for 3.x ). However when we implement the new coyote hooks, if all goes as planned ( and Interceptor/Valve will be particular cases of the new hooks ) then MxInteceptor will not be needed. > [ ] 3. I'd like to MxInterceptor and old layout, I'd rather like to > have a copy of DynamicMBeanProxy from jtc/util located in > a location compatible with container/lib (to be in > container_util.jar we could copy it in org.apache.tomcat.util.mx) That's possible - but given 5.0 I think it would be waste of time. > [ ] 4. I'd like to use MxInterceptor, keep the old layout, but don't > want to make the copy and could provide some code to avoid that. +1 Costin > > > Personally, I'd like solution 4 (but don't know how to), so I'll be > pragmatic and retains 3. -- Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
