Thanks Pablo,
Should this be addressed? The practical impact is sometimes an
application will deploy fine in Geronimo/Tomcat but not Geronimo/Jetty
(because it will use jars unavailable in the former) or the other way
around (because app jars will conflict with Geronimo's, as already
Our long term goal is to isolate web applications from the system
classes. This means that by default a web application will only see
the spec jars required by the servlet spec. Then if an application
needs more jars, they can either add them to the WEB-INF/lib or the
geronimo repository
. Maybe that assumption is incorrect!!??
- Ray Clough
-Original Message-
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 13, 2006 9:53 AM
To: user@geronimo.apache.org
Subject: Re: commons logging issue
Our long term goal is to isolate web applications from
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
@geronimo.apache.org
Subject: Re: commons logging issue
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
Paul McMahan wrote:
I'm not sure why deployment didn't fail in jetty, perhaps you would
have seen a failure later on when you tried to access your
servlets(?).
Hi,
I recall noticing a few days ago some jars missing from
Geronimo/Jetty /repository when compared to Geronimo/Tomcat.
Hi guys.
When I deploy my webapp in geronimo-1.0-jetty everything works fine but
when I do it in geronimo-1.0-tomcat I get the following error:
You have more than one version of 'org.apache.commons.logging.Log'
visible, which is not allowed.
Is this issue known? Will it be fixed in the near
Pablo, I think the problem is that your app includes a copy of the
commons logging and the server's classloader (which is visible to your
app) does too. Try adding this to your deployment plan:
web-app
hidden-classes
filterorg.apache.commons.logging/filter
/hidden-classes
Paul McMahan wrote:
Pablo, I think the problem is that your app includes a copy of the
commons logging and the server's classloader (which is visible to your
app) does too. Try adding this to your deployment plan:
web-app
hidden-classes
filterorg.apache.commons.logging/filter
Yeah, I've seen this issue before, and I can't remember what was done
to work around it. But the hidden classes is a good place to start.
Thanks,
Aaron
On 4/7/06, Pablo [EMAIL PROTECTED] wrote:
Paul McMahan wrote:
Pablo, I think the problem is that your app includes a copy of the
10 matches
Mail list logo
