You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Etienne Giraudy <eg...@gmail.com> on 2007/03/03 17:15:31 UTC
Migration from 5.5.20 to 6.0.10: parser issue on application deployment
Hi,
I'm facing a small issue when migrating a production server from 5.5.20 to
6.0.10 (see the exception below).
One of the web app running on that server includes xercesImpl.jar and use it
through modifying the system property javax.xml.parsers.SAXParserFactory.
This was not a problem in 5.5.x, but with 6.0.10, it seems that tomcat loads
its instance of the parser after web initializations. It is then affected by
the web app that modified the system property.
I've been able to 'fix' that by copying the xercesImpl.jar into tomcat lib
directory.
Shall this be considered as a regression as in that case tomcat
configuration is somehow altered by a web app?
(in that case I'll fill a bug in bugzilla))
Regards,
Etienne
GRAVE: Erreur lors du déploiement du répertoire portal de l'application web
javax.xml.parsers.FactoryConfigurationError: Provider
org.apache.xerces.jaxp.SAXParserFactoryImpl not found
at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:134)
at org.apache.tomcat.util.digester.Digester.getFactory(Digester.java:487)
at org.apache.tomcat.util.digester.Digester.getParser (Digester.java:692)
at org.apache.tomcat.util.digester.Digester.getXMLReader(Digester.java:900)
at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1581)
at org.apache.tomcat.util.modeler.modules.MbeansDescriptorsDiges
terSource.execute (MbeansDescriptorsDigesterSource.java:227)
at org.apache.tomcat.util.modeler.modules.MbeansDescriptorsDiges
terSource.loadDescriptors(MbeansDescriptorsDigesterSource.java:210)
at org.apache.tomcat.util.modeler.Registry.load (Registry.java:753)
at org.apache.tomcat.util.modeler.Registry.loadDescriptors(Registry.java
:865)
at org.apache.tomcat.util.modeler.Registry.loadDescriptors(Registry.java
:843)
at org.apache.tomcat.util.modeler.Registry.findDescriptor (Registry.java
:907)
at org.apache.tomcat.util.modeler.Registry.findManagedBean(Registry.java
:627)
at org.apache.tomcat.util.modeler.Registry.findManagedBean(Registry.java
:962)
at org.apache.tomcat.util.modeler.Registry.registerComponent (Registry.java
:793)
at org.apache.catalina.core.StandardWrapper.registerJMX(StandardWrapper.java
:1801)
at org.apache.catalina.core.StandardContext.registerJMX(StandardContext.java
:5200)
at org.apache.catalina.core.StandardContext.start (StandardContext.java
:4374)
at org.apache.catalina.core.ContainerBase.addChildInternal(
ContainerBase.java:761)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:741)
at org.apache.catalina.core.StandardHost.addChild (StandardHost.java:525)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java
:920)
at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java
:883)
at org.apache.catalina.startup.HostConfig.deployApps (HostConfig.java:492)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java
:311)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent (
LifecycleSupport.java:120)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1023)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
at org.apache.catalina.core.ContainerBase.start (ContainerBase.java:1015)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:448)
at org.apache.catalina.core.StandardServer.start (StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Re: Migration from 5.5.20 to 6.0.10: parser issue on application deployment
Posted by Rémy Maucherat <re...@gmail.com>.
On 3/3/07, Etienne Giraudy <eg...@gmail.com> wrote:
> Shall this be considered as a regression as in that case tomcat
> configuration is somehow altered by a web app?
> (in that case I'll fill a bug in bugzilla))
I don't think there can be a change of behavior in this sort of thing
between TC 5.5 and 6.0.
Rémy
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Migration from 5.5.20 to 6.0.10: parser issue on application deployment
Posted by Etienne Giraudy <eg...@gmail.com>.
> To see how "standard" and "legal" this usage is, you can try enabling
> the security manager (the only way to control writing to system
> properties - which are always JVM wide, so since Tomcat uses JAXP,
> Tomcat cannot avoid being affected to some extent when a webapp
> changes the parser factory - is to use the security manager) :) The
> other problem is that this by defeinition won't behave the same in
> different VMs (1.4, and same if you have a 5.0 VM with the
> compatibility pack for TC 5.5).
Not allowing the application to modify this system property is not an
option for me.
>
> You can send me a WAR to test however, I would be interested to look
> at this alleged difference in behavior.
>
I've filled a bug report to which I attached a simple web app for
reproducing the issue:
http://issues.apache.org/bugzilla/show_bug.cgi?id=41759
Etienne
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Migration from 5.5.20 to 6.0.10: parser issue on application deployment
Posted by Rémy Maucherat <re...@gmail.com>.
On 3/4/07, Etienne Giraudy <eg...@gmail.com> wrote:
> I guess that the point that is questionnable here is the way the API
> is designed: modifying the system property 'legal' and, AFAIK, it is
> the only way to choose the parser implementation we want to use
> (http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/parsers/SAXParser.html).
>
> From that point of view, shouldn't Tomcat protect itself against
> bad-designed standard APIs usage?
To see how "standard" and "legal" this usage is, you can try enabling
the security manager (the only way to control writing to system
properties - which are always JVM wide, so since Tomcat uses JAXP,
Tomcat cannot avoid being affected to some extent when a webapp
changes the parser factory - is to use the security manager) :) The
other problem is that this by defeinition won't behave the same in
different VMs (1.4, and same if you have a 5.0 VM with the
compatibility pack for TC 5.5).
You can send me a WAR to test however, I would be interested to look
at this alleged difference in behavior.
Rémy
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Migration from 5.5.20 to 6.0.10: parser issue on application deployment
Posted by Etienne Giraudy <eg...@gmail.com>.
On 3/3/07, Caldarale, Charles R <Ch...@unisys.com> wrote:
> > From: Etienne Giraudy [mailto:egiraudy@gmail.com]
> > Subject: Migration from 5.5.20 to 6.0.10: parser issue on
> > application deployment
> >
> > One of the web app running on that server includes
> > xercesImpl.jar and use it through modifying the system
> > property javax.xml.parsers.SAXParserFactory.
>
> That behavior looks rather questionable to me. Having a webapp modify a
> global property that has the potential of affecting everything running
> in that JVM - including other webapps and the container - seems like a
> very risky strategy, raising serious compatibility and operability
> issues. The fact that it happened to work in one version of one
> container doesn't imply that it's an appropriate thing to do.
>
I guess that the point that is questionnable here is the way the API
is designed: modifying the system property 'legal' and, AFAIK, it is
the only way to choose the parser implementation we want to use
(http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/parsers/SAXParser.html).
>From that point of view, shouldn't Tomcat protect itself against
bad-designed standard APIs usage?
Etienne
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Migration from 5.5.20 to 6.0.10: parser issue on application deployment
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Etienne Giraudy [mailto:egiraudy@gmail.com]
> Subject: Migration from 5.5.20 to 6.0.10: parser issue on
> application deployment
>
> One of the web app running on that server includes
> xercesImpl.jar and use it through modifying the system
> property javax.xml.parsers.SAXParserFactory.
That behavior looks rather questionable to me. Having a webapp modify a
global property that has the potential of affecting everything running
in that JVM - including other webapps and the container - seems like a
very risky strategy, raising serious compatibility and operability
issues. The fact that it happened to work in one version of one
container doesn't imply that it's an appropriate thing to do.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org