---------------------------------------------------------------------------
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" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <users@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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
