Actually, thats not the way it works. Classloaders form a hierachy. At the
top of the tree there is the bootstrap classloader. Underneath there is a
URL classloader, followed by orion's (1 or more) own classloaders. You're
right that each application then gets it's own classloader, but it's always
a child of one of orion's classlaoders. Since classloaders always delegate
to their parents, classes will always be loaded from the highest level
possible. Now I don't think xerces is part of orion's internal classpath
anymore (1.5.2), so I'm not sure why it's having a conflict, but in general
keep in mind that classes are always loaded at the top.
Andre
-----Original Message-----
From: Vimal Kansal [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 03, 2001 4:48 PM
To: Orion-Interest
Subject: Re: xerces conflict (and a hack solution).
I also ran into this problem. I think this is a bug
with Orion. Each application deployed to Orion should
get its own unique classloader, which is distinct not
only from all other applications, it is also distinct
from the classloader that Orion uses for itself.
Vimal
--- Mark Kettner <[EMAIL PROTECTED]> wrote:
> :Hello all,
>
> In our web application we use an old version of
> xerces. We deploy the
> application with xerces.jar in the
> WEB-INF/lib directory.
> However, when the application is started we get the
> error:
>
> java.lang.ClassNotFoundException:
> org.apache.xerces.parsers.SAXParser
> at
>
org.xml.sax.helpers.XMLReaderFactory.createXMLReader(XMLReaderFactory.java:1
18)
> at
>
com.fredhopper.frob.question.QuestionManager.loadQuestions(QuestionManager.j
ava:163)
> at
>
com.fredhopper.frob.question.QuestionManager.loadQuestions(QuestionManager.j
ava:78)
> at
>
com.fredhopper.frob.FredEngine.init(FredEngine.java:373)
> at
>
com.fredhopper.frob.FredEngine.startingUp(FredEngine.java:138)
> at
>
com.fredhopper.jsp.Bridge$EngineInServletContainer.fredhopper(Bridge.java:83
7)
> at
>
com.fredhopper.jsp.Bridge$EngineInServletContainer.run(Bridge.java:779)
>
> A bit cryptic, because SAXParser is in fact
> available twice (once in our
> application and once in the
> 'global' orion space).
>
> A solution is:
> 1) Move the following jars:
> crimson.jar
> jaxp.jar
> parser.jar
> xalan.jar
> 2) Move our own xerces.jar in orion home directory
> 2) Start orion as follows:
> java -Xbootclasspath/a:xerces.jar -jar orion.jar
>
> This is not a real solution, because we also had to
> remove the encoding
> attribute out of the application.xml and web.xml.
> And this should then
> be done for every application you deploy on the
> application server.
>
> Shouldn't it be that when the application server
> looks for a class, it
> first looks in the classes directory of that web
> application, then in
> the lib directory of the web application and if it
> still can't resolve
> the class it looks in the global space (not a good
> idea, since this
> depends on which application server you use, but
> trade of to save memory
> usage)?
> So is this a bug in orion, or are we doing something
> wrong here?
>
> Mark
>
> --
> --o-o----------
> Mark Kettner
> http://www.fredhopper.com
> Amsterdam, The Netherlands
> Phone: +31 20 3206203 Mobile: +31 620 609 817
> fax: +31 20 8848747
> E-mail: [EMAIL PROTECTED], [EMAIL PROTECTED]
>
>
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
