You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@tomcat.apache.org by Tony Fountain <tf...@benefitconcepts.com> on 2007/10/26 15:43:17 UTC

Class loading issue

Windows 2003 Server
Apache Tomcat 5.5.23 (running as Windows service)
JVM 1.5.0_12b-04 (Sun)
 
In an attempt to have a specific web app load when Apache starts, I
added the following element to the \WEB-INF\web.xml file for the
appropriate servlet - <load-on-startup>1</load-on-startup>.  This works,
but when the webapp loads, one of the classes it requires generates an
error the first time the webapp is accessed via the browser.  The class
is contained in a JAR that resides in the \WEB-INF\lib folder.  This
webapp is not written by us, rather it's a product we purchased.  At the
suggestion of the vendor I moved the JAR file to the \Tomcat\common\lib
folder and everything now works just fine.  I've reviewed the
documentation on class loading in Tomcat 5.5 but this still makes no
sense to me in terms of why this happens and why moving it fixed it.
According to this documentation, the \WEB-INF\lib solution should work
just fine.  Any thoughts?  Note that if I do not attempt to load on
startup then everything works fine (just takes several seconds for the
webapp to load upon the initial access).
 
Thanks,
Tony

---------------------------------------------------------------------
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: Class loading issue

Posted by Johnny Kewl <jo...@kewlstuff.co.za>.

---------------------------------------------------------------------------
HARBOR: http://coolharbor.100free.com/index.htm
Now Tomcat is also a cool pojo application server
---------------------------------------------------------------------------

Hi Tony, I been following this thread with great interest, because it is as 
confusing as hell.

I think there must be a subtle change in the start up sequence with 
<load-on-startup>

The thing that has really got me wondering is that some of these classes 
listed in the error message as far as I know... are not part of TC...

For example org.apache.commons.modeler.modules.MbeansDescriptorsDOMSource is 
not inside TC
That class inside TC is in
org.apache.tomcat.util.modeler.modules.MbeansDescriptorsDOMSource;

Similar names... but its not code inside TC that is bitchin... or maybe it 
is because something has told it to use a class that it doesnt have.

Its impossible for TC to see the classes in the WEB-APP, classloaders dont 
look down, they look up... but if for some reason, this XML parser kicks off 
with <load-on-startup>... it can look up... and I think thats where the 
problem is.
Because packages like Xerces are so big, I think when it was designed for 
TC( version ancient history), they didnt include all the classes, ie they 
said, oh look TC( version ancient history),  uses XML parser (version 
ancient history), as well and we dont have to include all of it... now when 
it looks up, it kicks off classes that confuse the other XML parsers.

Its concerning because it does imply there is some kind of race condition, 
if the old XML parser gets in before TC's built in parser... weird stuff 
happens.

I would try move up to TC 6 (has a simpler classloader scheme), in the hope 
that it works, or breaks and stays broken, so that the actual cause can be 
found.
These XML parsers have strange interdependencies, even outside of 
application servers, so much so that we ended up making our own lite version 
just because we know it cant get bombed by some other packages XML parser. 
Its as much an issue with these XML parsers as it is with TC.... 
unfortunately.

I think when you move it out of the WEB-APP, its not becoming the main XML 
parser, its just changing the sequence that these things start up, ie TC is 
getting in first.

You know what would be interesting... <load-on-startup> can take sequence 
numbers.... so make some other servlet have <load-on-startup>1
and this one say <load-on-startup>100.... Have a feeling the problem will go 
away, but wont be fixed.

Short of this... going to have to ask the supplier very nicely for the 
relevant code.... or we all going to be guessing forever ;)
You see in the TC notes that the guys have made special exceptions for XML 
parsers (for some reason), as soon as this kind of thing has to happen, it 
opens bug doors for this sort of thing... why XML parsers cant be made 
completely (new Class) isolatable, beats me, but thats where all the trouble 
starts.
As soon as you have something in a fenced off class loader that *must* look 
up, it has no choice.... it becomes impossible to isolate the system.
I see this same kind of error in other application servers as well.... also 
completely unresolved...

Personally I think another look at XML parsers is needed.... these things 
are trouble.

Good Luck....



 Caused by: javax.xml.parsers.FactoryConfigurationError: Provider
 org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found
 at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown
 Source)
 at
 org.apache.commons.modeler.util.DomUtil.readXml(DomUtil.java:241)
 at
 org.apache.commons.modeler.modules.MbeansDescriptorsDOMSource.execute(Mb
 eansDescriptorsDOMSource.java:87)
 at




----- Original Message ----- 
From: "Tony Fountain" <tf...@benefitconcepts.com>
To: "Tomcat Users List" <us...@tomcat.apache.org>
Sent: Friday, October 26, 2007 3:43 PM
Subject: Class loading issue


Windows 2003 Server
Apache Tomcat 5.5.23 (running as Windows service)
JVM 1.5.0_12b-04 (Sun)

In an attempt to have a specific web app load when Apache starts, I
added the following element to the \WEB-INF\web.xml file for the
appropriate servlet - <load-on-startup>1</load-on-startup>.  This works,
but when the webapp loads, one of the classes it requires generates an
error the first time the webapp is accessed via the browser.  The class
is contained in a JAR that resides in the \WEB-INF\lib folder.  This
webapp is not written by us, rather it's a product we purchased.  At the
suggestion of the vendor I moved the JAR file to the \Tomcat\common\lib
folder and everything now works just fine.  I've reviewed the
documentation on class loading in Tomcat 5.5 but this still makes no
sense to me in terms of why this happens and why moving it fixed it.
According to this documentation, the \WEB-INF\lib solution should work
just fine.  Any thoughts?  Note that if I do not attempt to load on
startup then everything works fine (just takes several seconds for the
webapp to load upon the initial access).

Thanks,
Tony

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



---------------------------------------------------------------------
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: Class loading issue

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.

> From: Konstantin Kolinko [mailto:knst.kolinko@gmail.com] 
> Subject: Re: Class loading issue
> 
> Nevertheless, the official path to provide a custom XML parsing
> library is to use the endorsing mechanism. See "XML Parsers and J2SE
> 1.4", "XML Parsers and JSE 5" chapters in class-loader-howto.html

That doc is somewhat incorrect, in particular this statement:

"In previous versions of Tomcat 5, you could simply replace the XML
parser in the $CATALINA_HOME/common/lib directory to change the parser
used by all web applications. However, this technique will not be
effective when you are running on J2SE 1.4, because the usual class
loader delegation process will always choose the implementation inside
the JDK in preference to this one."

It ignores the ability to override the JRE/JDK implementation by using
the appropriate system property or the JAR Service Provider mechanism.
I suspect the latter is why placing the oddly named a_xercesImpl.jar in
common/lib allows things to "work".

Setting -Djaxp.debug=true might generate some light on the issue.

 - 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

Re: Class loading issue

Posted by Konstantin Kolinko <kn...@gmail.com>.

Tony,

have you seen

http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html
http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html

In general, implementing classloader hierarchies, as the one in tomcat
5.5, is not a simple matter.

Citing from those pages:
"As mentioned above, the web application class loader diverges from
the default Java 2 delegation model (in accordance with the
recommendations in the Servlet Specification, version 2.3, section
9.7.2 Web Application Classloader)"

Thus sometimes there are issues.

Even there may be bugs somewhere.

As for XML parsing:
My speculation is that the XML parsing library registers itself as
JAXP parser in the JVM, for the whole JVM, for the whole server. Thus,
wrecking the configuration. Because it cannot be used outside of the
web app.

> However, that does not clarify for me why it
> only happens when I attempt to set the <load-on-startup> element in the
> webapps web.xml file but if I do not autoload the class, it works just
> fine.

It runs fine just until there is a need to parse xml files somewhere
outside of your web app. At the moment this parsing happens (sooner or
later, as there are a plenty of configuration files), you will
encounter the issue.  E.g. try to deploy a second war file, and you
may see the issue.

Placing the parser jar into common/lib does work, if you consider the
classloaders hierarchy.

Nevertheless, the official path to provide a custom XML parsing
library is to use the endorsing mechanism. See "XML Parsers and J2SE
1.4", "XML Parsers and JSE 5" chapters in class-loader-howto.html

Chuck wrote:
> I'm not sure if there's any means of specifying a webapp-local XML
> parser rather than a global one; others may have more experience here.

Best regards,
- Konstantin.

2007/10/26, Tony Fountain <tf...@benefitconcepts.com>:
> Thanks for the response.  However, that does not clarify for me why it
> only happens when I attempt to set the <load-on-startup> element in the
> webapps web.xml file but if I do not autoload the class, it works just
> fine.  As far as the JAVA_OPTS go, I do not see where I have this set at
> all.  I'm running Apache Tomcat 5.5.23 as a windows service.  In the
> properties under Java, I am setting these options:
>
> -Dcatalina.home=C:\Apache\Tomcat
> -Dcatalina.base=C:\Apache\Tomcat
> -Djava.endorsed.dirs=C:\Apache\Tomcat\common\endorsed
> -Djava.io.tmpdir=C:\Apache\Tomcat\temp
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -Djava.util.logging.config.file=C:\Apache\Tomcat\conf\logging.properties
>
> Thanks,
> Tony
>
> -----Original Message-----
> From: Caldarale, Charles R [mailto:Chuck.Caldarale@unisys.com]
> Sent: Friday, October 26, 2007 12:18 PM
> To: Tomcat Users List
> Subject: RE: Class loading issue
>
> > From: Tony Fountain [mailto:tfountain@benefitconcepts.com]
> > Subject: RE: Class loading issue
> >
> > Caused by: javax.xml.parsers.FactoryConfigurationError: Provider
> > org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found
>
> It looks like you must have the system property
> javax.xml.parsers.DocumentBuilderFactory set to point to
> org.apache.xerces.jaxp.DocumentBuilderFactoryImpl (e.g., via JAVA_OPTS).
> This forces all XML scanning to go through that class, including any
> done by Tomcat itself.  Consequently, the above class must be made
> visible to the Tomcat internal classes, so putting the jar into
> common/lib is required.
>
> I'm not sure if there's any means of specifying a webapp-local XML
> parser rather than a global one; others may have more experience here.
>
>  - 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