Ray,
If I understood the discussions around this topic that happened
this week, the problem you noticed has to do with conflicts between
WEB-INF/lib jars and Geronimo jars, because currently they share the
same classloader. Sticking to the track of this thread, you may try to
deploy your war to Geronimo/Jetty and most likely won't have any
problems, because its repository does not have a copy of this jar.
There are two workarounds for this that I am aware of:
1. Add the container-specific geronimo-web.xml to WEB-INF (or tell the
deployer which one to use when you deploy your app) and make sure it has
something like...
<hidden-classes><filter>org.apache.commons.logging</filter></hidden-classes>
2. Remove commons-logging.jar from your app so the repository version
will be used instead. I believe this is what you did, right?
You could also erase commons-logging.jar from the repository, but I
don't think anyone would advise that.
Until the issue is dealt with, I think the best workaround for
similar problems is going with a geronimo-web.xml given to the
classloader at deploy time, and not inside your WEB-INF, so the app
remains proprietary descriptor free. If you erase the jar from it, you
may have problems deploying it to other servers.
Hope this helps,
Guilherme
Clough, Ray C PWR escreveu:
I have found that if the commons-logging.jar file is in my app's lib
directory, then Geronimo chokes on it. However, deployments of the
exact same WAR file on Tomcat, Sun, Oracle servers work fine if the
commons-logging.jar file is present. I always figured it was a class
loader error in Geronimo. Maybe that assumption is incorrect!!??
- Ray Clough
___________________________________________________________
Switch an email account to Yahoo! Mail, you could win FIFA World Cup tickets. http://uk.mail.yahoo.com
