You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Vjeran Marcinko <vj...@tis.hr> on 2004/07/27 13:51:40 UTC
Turbine2.3 and commons-logging in Tomcat5
Hi folks.
Current version of Turbine 2.3 doesn't work in Tomcat5 because Tomcat's
classloader system uses commons-logging.jar and jmx.jar before looking into
some .war (they call it system classpath which has higher priority than war
libs). It wouldn't be a problem if Turbine's servlet doesn't use
Log4JFactory (from commons-logging's *implementation package*, not API)
which is excluded in newer versions of commons-logging. Is there some
compiled version of Turbine 2.3 with this problem fixed ?
Regards,
Vjeran
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Turbine2.3 and commons-logging in Tomcat5
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Vjeran Marcinko" <vj...@tis.hr> writes:
I plan to put a patch for this into 2.3.1 (using
commons-logging.properties and no longer hard-code the log4j factory).
However, for me, Turbine based applications run fine with Tomcat
5.0.25 to 5.0.27. Never had any problems. I use the Tomcat5 from jpackage
for deployment and the binary releases from jakarta for testing.
What errors do you see? Do you have any special configuration done
to server.xml?
Regards
Henning
>Hi folks.
>Current version of Turbine 2.3 doesn't work in Tomcat5 because Tomcat's
>classloader system uses commons-logging.jar and jmx.jar before looking into
>some .war (they call it system classpath which has higher priority than war
>libs). It wouldn't be a problem if Turbine's servlet doesn't use
>Log4JFactory (from commons-logging's *implementation package*, not API)
>which is excluded in newer versions of commons-logging. Is there some
>compiled version of Turbine 2.3 with this problem fixed ?
>Regards,
>Vjeran
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-user-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems."
-- Michelle Levesque, "Fundamental Issues with
Open Source Software Development"
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Turbine2.3 and commons-logging in Tomcat5
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Vjeran Marcinko" <vj...@tis.hr> writes:
>Hi folks.
>Current version of Turbine 2.3 doesn't work in Tomcat5 because Tomcat's
>classloader system uses commons-logging.jar and jmx.jar before looking into
>some .war (they call it system classpath which has higher priority than war
>libs). It wouldn't be a problem if Turbine's servlet doesn't use
I remember reading about this on http://www.hibernate.org/114.html
--- cut ---
This was expected, because Tomcat "sometimes" (actually, this is the
difference between the standard JDK classloader concept and the
"broken" Servlet specification) has a different delegation strategy
for its classloaders:
The classloader at the common/lib and common/classes level is not the
same as the context classloader, responsible for a specific
WEB-INF/lib and WEB-INF/classes. You would expect that every
loadClass(), new and Class.forName() call in your application results
in a search at the current level and then a delegation to the upper
level classloader if no class can be found. This is not the case! The
default is to first search with the parent classloader and if he can
not find the class, with its parent classloader. This chain of
responsibility continues up to the top of the classloader delegation
hierarchy. Only if no classloader in the chain can find your requested
class, your context classloader will get a chance to try it.
One way to modify this behaviour (and you usually want it different)
is to work with the <loader> directive in Tomcats server.xml (in the
declaration of each context):
<Loader checkInterval="1" delegate="false"/>
This turns on auto-reloading of classes (one second check time),
useful in development. It also prevents the delegation to the parent
classloader: The context classloader gets the first chance to find the
class for your application. The default of this attribute (true or
false) seems to vary from Tomcat version to version. Much of the
classloading problems in Tomcat (the broken commons-logging and log4j,
for example) stems from this simple fact.
--- cut ---
You might want to try "delegate="false". The "checkInterval" is a bad
idea for a production system (a good one for debugging, though).
Let me know if this works for you.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems."
-- Michelle Levesque, "Fundamental Issues with
Open Source Software Development"
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: Turbine2.3 and commons-logging in Tomcat5
Posted by Eric Pugh <ep...@upstate.com>.
Not that I know of, but a patch would be much appreciated!
> -----Original Message-----
> From: Vjeran Marcinko [mailto:vjeran@tis.hr]
> Sent: Tuesday, July 27, 2004 1:52 PM
> To: turbine-user@jakarta.apache.org
> Subject: Turbine2.3 and commons-logging in Tomcat5
>
>
> Hi folks.
>
> Current version of Turbine 2.3 doesn't work in Tomcat5 because Tomcat's
> classloader system uses commons-logging.jar and jmx.jar before
> looking into
> some .war (they call it system classpath which has higher
> priority than war
> libs). It wouldn't be a problem if Turbine's servlet doesn't use
> Log4JFactory (from commons-logging's *implementation package*, not API)
> which is excluded in newer versions of commons-logging. Is there some
> compiled version of Turbine 2.3 with this problem fixed ?
>
> Regards,
> Vjeran
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org