Re: [POLL] Tomcat 3.3.2 updates
Larry Isaacs wrote: -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 5:55 AM To: Tomcat Developers List Subject: Re: [POLL] Tomcat 3.3.2 updates http://jakarta.apache.org/~larryi/JmxSupport.war I take a look at this module and I really like it. What about using it and remove MxInterceptor ? Yes, I would remove MxInterceptor, and related items from the main tree and add JmxSupport (suggestions for a better name are welcome) under proposals. Could we bundle this module in TC 3.3.2 ? My first thought is to make it available in the same fashion as PasswordPrompter.war. Also, I don't think it will interfere with JMX use in web applications since add-ons, being trusted, hook to the container classloader. So you've got my total +1 to put JMX in module and remove MxInterceptor ;-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [POLL] Tomcat 3.3.2 updates
Think about it - each app can expose config and status data to the mx layer, and the config app ( or another tool ) can manage not only tomcat, but also each webapp. JMX is not restricted to server code, it can ( and should) be used in user apps as well. And that's where things will be intersting. As someone who write large web applications, I added JMX support directly into the application, so I'd like to keep control on it, ie creating JMX, JMX HTTP adaptor. I don't think the servlet engine should do it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [POLL] Tomcat 3.3.2 updates
-Original Message- From: Costin Manolache [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 9:21 AM To: [EMAIL PROTECTED] Subject: RE: [POLL] Tomcat 3.3.2 updates Larry Isaacs wrote: A first pass implementation, derived from what you have done, can be found here: http://jakarta.apache.org/~larryi/JmxSupport.war Great ! However, I remain to the opinion that JMX is a fundamental API that should be available to all applications, and it should provide it's own (trusted) security. If anything, we should try to 'hack' mx4j to provide app isolation or fix whatever is broken. Most of the time I have spent playing with JMX occurred in the last couple of days. So that I don't misunderstand, can you elaborate what you mean by isolation. Are you referring to some kind of username, and maybe rolls, that somehow control what you can and can't see on the Mbean server? Think about it - each app can expose config and status data to the mx layer, and the config app ( or another tool ) can manage not only tomcat, but also each webapp. JMX is not restricted to server code, it can ( and should) be used in user apps as well. And that's where things will be intersting. For now, we could continue to include the JMX jars in lib/container and update LoaderInterceptor11 to have jmx, jmxDir, and jmxJars attributes which work like the JAXP handling. Do you see doing more than this at this point? Cheers, Larry Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [POLL] Tomcat 3.3.2 updates
I'll try to commit this tonight. Cheers, Larry -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 4:38 AM To: Tomcat Developers List Subject: Re: [POLL] Tomcat 3.3.2 updates Larry Isaacs wrote: -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 5:55 AM To: Tomcat Developers List Subject: Re: [POLL] Tomcat 3.3.2 updates http://jakarta.apache.org/~larryi/JmxSupport.war I take a look at this module and I really like it. What about using it and remove MxInterceptor ? Yes, I would remove MxInterceptor, and related items from the main tree and add JmxSupport (suggestions for a better name are welcome) under proposals. Could we bundle this module in TC 3.3.2 ? My first thought is to make it available in the same fashion as PasswordPrompter.war. Also, I don't think it will interfere with JMX use in web applications since add-ons, being trusted, hook to the container classloader. So you've got my total +1 to put JMX in module and remove MxInterceptor ;-) -- To unsubscribe, e-mail: mailto:tomcat-dev- [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]
Re: [POLL] Tomcat 3.3.2 updates
Henri Gomez wrote: Larry Isaacs wrote: -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 5:55 AM To: Tomcat Developers List Subject: Re: [POLL] Tomcat 3.3.2 updates http://jakarta.apache.org/~larryi/JmxSupport.war I take a look at this module and I really like it. What about using it and remove MxInterceptor ? Yes, I would remove MxInterceptor, and related items from the main tree and add JmxSupport (suggestions for a better name are welcome) under proposals. Could we bundle this module in TC 3.3.2 ? My first thought is to make it available in the same fashion as PasswordPrompter.war. Also, I don't think it will interfere with JMX use in web applications since add-ons, being trusted, hook to the container classloader. So you've got my total +1 to put JMX in module and remove MxInterceptor ;-) +1 from me to. ( and sorry for creating the mess in the first place by puting it in the main tree ) -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [POLL] Tomcat 3.3.2 updates
Larry Isaacs wrote: -Original Message- From: Costin Manolache [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 9:21 AM To: [EMAIL PROTECTED] Subject: RE: [POLL] Tomcat 3.3.2 updates Larry Isaacs wrote: A first pass implementation, derived from what you have done, can be found here: http://jakarta.apache.org/~larryi/JmxSupport.war Great ! However, I remain to the opinion that JMX is a fundamental API that should be available to all applications, and it should provide it's own (trusted) security. If anything, we should try to 'hack' mx4j to provide app isolation or fix whatever is broken. Most of the time I have spent playing with JMX occurred in the last couple of days. So that I don't misunderstand, can you elaborate what you mean by isolation. Are you referring to some kind of username, and maybe rolls, that somehow control what you can and can't see on the Mbean server? 1. It should be possible to have multiple jmx-enabled webapps, each with a number of MBeans. 2. Webapps shouldn't be able to 'see' each other or to see the container domain. 3. The (jmx) connectors must be shared ( you can't have one SNMP or http adapter for each app ) AFAIK this will probably require some jmx implementation specific code, since the jmx itself doesn't seem to have anything to help. ( this is common for all containers ) Think about it - each app can expose config and status data to the mx layer, and the config app ( or another tool ) can manage not only tomcat, but also each webapp. JMX is not restricted to server code, it can ( and should) be used in user apps as well. And that's where things will be intersting. For now, we could continue to include the JMX jars in lib/container and update LoaderInterceptor11 to have jmx, jmxDir, and jmxJars attributes which work like the JAXP handling. Do you see doing more than this at this point? +1 Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [POLL] Tomcat 3.3.2 updates
Henri Gomez wrote: Think about it - each app can expose config and status data to the mx layer, and the config app ( or another tool ) can manage not only tomcat, but also each webapp. JMX is not restricted to server code, it can ( and should) be used in user apps as well. And that's where things will be intersting. As someone who write large web applications, I added JMX support directly into the application, so I'd like to keep control on it, ie creating JMX, JMX HTTP adaptor. I don't think the servlet engine should do it. Of course not. But the JMX API should be available to your application. You can include it in WEB-INF for each app - but then what do you do, have one HTTP adaptor ( or SNMP adaptor ) for each app ? In a multi-app env, each app can be JMX-enabled ( and have it's own domain ). It is the servlet engine ( or a module in the servlet engine ) that must isolate the webapps - since JMX itself has no idea or knowledge about the container. But nothng else - the container should just make sure the jmx is available and the apps are isolated and the security settings are right. -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [POLL] Tomcat 3.3.2 updates
Larry Isaacs wrote: Hi Henri, The basic problem is that o.a.t.u.mx.DynamicMBeanProxy.java carries dependencies, which imposes requirements on the classloader hierarchy for any class that uses it. In this case the jmx, parser, and tranform jars would need to move to lib/common where tomcat-util.jar lives. I would be in favor of sacrificing code reuse to avoid these restrictions. I think this would be a lot easier than trying to implement classloader tricks. I think the best way of accomplishing this is to make the JMX support an add-on module with its own local copy of DynamicMBeanProxy. Then, there is no impact on classloaders and enabling is simply dropping a war file in the modules directory. A first pass implementation, derived from what you have done, can be found here: http://jakarta.apache.org/~larryi/JmxSupport.war It contains the mx4j jars, so they aren't needed in lib/container. If this approach is acceptable, I can update the jakarta-tomcat build to include it. Note: You will need the recent TrustedLoader.java update before add-ons will deploy successfully. If this solution allow use of JMX without having to put jmx/jmx-tools and xerces/xalan in common/lib I'm +1. Also did it allow a webapp to use it's own JMX ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [POLL] Tomcat 3.3.2 updates
http://jakarta.apache.org/~larryi/JmxSupport.war I take a look at this module and I really like it. What about using it and remove MxInterceptor ? Could we bundle this module in TC 3.3.2 ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [POLL] Tomcat 3.3.2 updates
Bill Barker wrote: My first choice is still for split-jars in j-t-c util. In TC 4.1.x/5.0 both jars go to server/lib (same as 3.3 lib/container). So Costin's dream of every servlet being able to access JMX still requires a [VOTE]. :-) In 3.3 we can send one to lib/container and one to lib/common. Easy, simple, secure. However, since Costin is already on record as vetoing split-jars, I'm +1 for this module. Sorry, I didn't meant it as a 'veto'. Usually 'veto' is used for code commits - on long term proposals like that a -1 is more 'I don't think this is the best idea'. And my reason is more that I don't want to add instability or code changes until the JMX is actually usefull - that requires adding getters for intersting information and implementing the config storage layer ( for 5.0, but that can be used for 3.3 too or anything else ). In addition, it may be a good moment to merge the class loader tricks and create a common loader and loader policy. Costin As much as I would really like JMX support, (with my webmaster hat on) I can't take it at the expense of choice of XML parsers. (Of course, this means nothing, since at the end of the day, I can (and will :) just edit my copy of j-t-c/util/build.xml). - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, September 24, 2002 10:10 PM Subject: RE: [POLL] Tomcat 3.3.2 updates Hi Henri, The basic problem is that o.a.t.u.mx.DynamicMBeanProxy.java carries dependencies, which imposes requirements on the classloader hierarchy for any class that uses it. In this case the jmx, parser, and tranform jars would need to move to lib/common where tomcat-util.jar lives. I would be in favor of sacrificing code reuse to avoid these restrictions. I think this would be a lot easier than trying to implement classloader tricks. I think the best way of accomplishing this is to make the JMX support an add-on module with its own local copy of DynamicMBeanProxy. Then, there is no impact on classloaders and enabling is simply dropping a war file in the modules directory. A first pass implementation, derived from what you have done, can be found here: http://jakarta.apache.org/~larryi/JmxSupport.war It contains the mx4j jars, so they aren't needed in lib/container. If this approach is acceptable, I can update the jakarta-tomcat build to include it. Note: You will need the recent TrustedLoader.java update before add-ons will deploy successfully. Cheers, Larry -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 6:32 PM To: Tomcat Developers List Subject: Re: [POLL] Tomcat 3.3.2 updates Bill Barker wrote: - Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, September 24, 2002 1:38 AM Subject: Re: [POLL] Tomcat 3.3.2 updates Larry Isaacs wrote: Hi Henri, I would prefer to minimize the impact of upgrading from 3.3.1 to 3.3.2. I agree with Costin that using 4 with documentation on the steps to enable the MxInterceptor would be a resonable way to implement this. So I'll have to take a look at MxInterceptor to see if nothing is broken ... BTW, I could spend sometimes to play ClassLoader, making MxInterceptor loading mx4j/mx4-tools from container ClassLoader but I need some advices. You can get the loader from ContextManager.getContainerLoader(). I tried to use it before loading JMX or JMXTOOLS class but it didn't works. Some working example are welcomed. -- To unsubscribe, e-mail: mailto:tomcat-dev- [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] -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [POLL] Tomcat 3.3.2 updates
Larry Isaacs wrote: A first pass implementation, derived from what you have done, can be found here: http://jakarta.apache.org/~larryi/JmxSupport.war Great ! However, I remain to the opinion that JMX is a fundamental API that should be available to all applications, and it should provide it's own (trusted) security. If anything, we should try to 'hack' mx4j to provide app isolation or fix whatever is broken. Think about it - each app can expose config and status data to the mx layer, and the config app ( or another tool ) can manage not only tomcat, but also each webapp. JMX is not restricted to server code, it can ( and should) be used in user apps as well. And that's where things will be intersting. Costin It contains the mx4j jars, so they aren't needed in lib/container. If this approach is acceptable, I can update the jakarta-tomcat build to include it. Note: You will need the recent TrustedLoader.java update before add-ons will deploy successfully. Cheers, Larry -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 6:32 PM To: Tomcat Developers List Subject: Re: [POLL] Tomcat 3.3.2 updates Bill Barker wrote: - Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, September 24, 2002 1:38 AM Subject: Re: [POLL] Tomcat 3.3.2 updates Larry Isaacs wrote: Hi Henri, I would prefer to minimize the impact of upgrading from 3.3.1 to 3.3.2. I agree with Costin that using 4 with documentation on the steps to enable the MxInterceptor would be a resonable way to implement this. So I'll have to take a look at MxInterceptor to see if nothing is broken ... BTW, I could spend sometimes to play ClassLoader, making MxInterceptor loading mx4j/mx4-tools from container ClassLoader but I need some advices. You can get the loader from ContextManager.getContainerLoader(). I tried to use it before loading JMX or JMXTOOLS class but it didn't works. Some working example are welcomed. -- To unsubscribe, e-mail: mailto:tomcat-dev- [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: [POLL] Tomcat 3.3.2 updates
-Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 5:55 AM To: Tomcat Developers List Subject: Re: [POLL] Tomcat 3.3.2 updates http://jakarta.apache.org/~larryi/JmxSupport.war I take a look at this module and I really like it. What about using it and remove MxInterceptor ? Yes, I would remove MxInterceptor, and related items from the main tree and add JmxSupport (suggestions for a better name are welcome) under proposals. Could we bundle this module in TC 3.3.2 ? My first thought is to make it available in the same fashion as PasswordPrompter.war. Also, I don't think it will interfere with JMX use in web applications since add-ons, being trusted, hook to the container classloader. Cheers, Larry -- To unsubscribe, e-mail: mailto:tomcat-dev- [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]
Re: [POLL] Tomcat 3.3.2 updates
Larry Isaacs wrote: Hi Henri, I would prefer to minimize the impact of upgrading from 3.3.1 to 3.3.2. I agree with Costin that using 4 with documentation on the steps to enable the MxInterceptor would be a resonable way to implement this. So I'll have to take a look at MxInterceptor to see if nothing is broken ... BTW, I could spend sometimes to play ClassLoader, making MxInterceptor loading mx4j/mx4-tools from container ClassLoader but I need some advices. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [POLL] Tomcat 3.3.2 updates
- Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, September 24, 2002 1:38 AM Subject: Re: [POLL] Tomcat 3.3.2 updates Larry Isaacs wrote: Hi Henri, I would prefer to minimize the impact of upgrading from 3.3.1 to 3.3.2. I agree with Costin that using 4 with documentation on the steps to enable the MxInterceptor would be a resonable way to implement this. So I'll have to take a look at MxInterceptor to see if nothing is broken ... BTW, I could spend sometimes to play ClassLoader, making MxInterceptor loading mx4j/mx4-tools from container ClassLoader but I need some advices. You can get the loader from ContextManager.getContainerLoader(). -- 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]
Re: [POLL] Tomcat 3.3.2 updates
Bill Barker wrote: - Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, September 24, 2002 1:38 AM Subject: Re: [POLL] Tomcat 3.3.2 updates Larry Isaacs wrote: Hi Henri, I would prefer to minimize the impact of upgrading from 3.3.1 to 3.3.2. I agree with Costin that using 4 with documentation on the steps to enable the MxInterceptor would be a resonable way to implement this. So I'll have to take a look at MxInterceptor to see if nothing is broken ... BTW, I could spend sometimes to play ClassLoader, making MxInterceptor loading mx4j/mx4-tools from container ClassLoader but I need some advices. You can get the loader from ContextManager.getContainerLoader(). I tried to use it before loading JMX or JMXTOOLS class but it didn't works. Some working example are welcomed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[POLL] Tomcat 3.3.2 updates
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. [ ] 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. [ ] 2. MxInterceptor is really needed, ok to change the layout, we'll warn users in Changelog / Readme [ ] 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) [ ] 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. Personally, I'd like solution 4 (but don't know how to), so I'll be pragmatic and retains 3. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [POLL] Tomcat 3.3.2 updates
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]
AW: [POLL] Tomcat 3.3.2 updates
Hi, since our application uses TopLink, we can not upgrade to xerces 2. There are hardcoded xerces 1 classes used directly from TopLink. So 2) is a showstopper for all people with 3rd party jars requiring xerces 1 MBeans are useful for us, but not required. We are already using mx4j and mx4j-tools in our webapp together with xerces 1.4.0 and xalan 2.1.0 My preference would be. Leave it as it is, but give a short readme hat to copy where to be abe to use MxInterceptor Thanks, Hans -Ursprungliche Nachricht- Von: Henri Gomez [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 23. September 2002 16:02 An: [EMAIL PROTECTED] Betreff: [POLL] Tomcat 3.3.2 updates 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. [ ] 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. [ ] 2. MxInterceptor is really needed, ok to change the layout, we'll warn users in Changelog / Readme [ ] 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) [ ] 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. Personally, I'd like solution 4 (but don't know how to), so I'll be pragmatic and retains 3. -- 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]
RE: [POLL] Tomcat 3.3.2 updates
Hi Henri, I would prefer to minimize the impact of upgrading from 3.3.1 to 3.3.2. I agree with Costin that using 4 with documentation on the steps to enable the MxInterceptor would be a resonable way to implement this. Cheers, Larry -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: Monday, September 23, 2002 10:02 AM To: [EMAIL PROTECTED] Subject: [POLL] Tomcat 3.3.2 updates 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. [ ] 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. [ ] 2. MxInterceptor is really needed, ok to change the layout, we'll warn users in Changelog / Readme [ ] 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) [ ] 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. Personally, I'd like solution 4 (but don't know how to), so I'll be pragmatic and retains 3. -- To unsubscribe, e-mail: mailto:tomcat-dev- [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]
Re: [POLL] Tomcat 3.3.2 updates
On Tue, 2002-09-24 at 00:01, Henri Gomez wrote: Thanks to give your opinion here. [X] 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. [ ] 2. MxInterceptor is really needed, ok to change the layout, we'll warn users in Changelog / Readme [ ] 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) [ ] 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. However, as long as I can: 1. Disable it completely in server.xml 2. Remove unwanted XML parser JAR's manually I'm OK with any, really. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
