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

Reply via email to