[ jetty-Bugs-937718 ] Jetty fails to load web application if log4j in lib folder

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[ jetty-Bugs-937718 ] Jetty fails to load web application if log4j in lib folder

SourceForge.net
Bugs item #937718, was opened at 2004-04-19 08:09
Message generated for change (Comment added) made by gregwilkins
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=107322&aid=937718&group_id=7322

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Other
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: robertrodewald (robertrodewald)
Assigned to: Greg Wilkins (gregwilkins)
Summary: Jetty fails to load web application if log4j in lib folder

Initial Comment:
Hi everybody,

I tried to run a very minimalistic jetty configuration
where jetty uses the SimpleLog from the commons-
logging project. I then added a very simple webapp with
1 servlet (which doesn't effectively do anything useful).
Everything was fine so far.
Then I just added the log4j-libraries to the lib folder of
the webapplication and the webapp couldn't start any
more.

Here is the stacktrace:
~~~~~~~~~~~~~~
19.04.2004 09:25:32 org.mortbay.http.HttpServer start
INFO: Started
org.mortbay.http.NCSARequestLog@1cd280b
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0
(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.
java:39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke
(Method.java:324)
        at org.mortbay.start.Main.invokeMain
(Main.java:140)
        at org.mortbay.start.Main.start(Main.java:458)
        at org.mortbay.start.Main.main(Main.java:83)
Caused by: java.lang.ExceptionInInitializerError
        at org.mortbay.util.Resource.newResource
(Resource.java:63)
        at org.mortbay.util.Resource.newSystemResource
(Resource.java:176)
        at
org.mortbay.jetty.servlet.XMLConfiguration.configureDefa
ults(XMLConfi
guration.java:82)
        at
org.mortbay.jetty.servlet.WebApplicationContext.start
(WebApplicationC
ontext.java:371)
        at org.mortbay.http.HttpServer.start
(HttpServer.java:668)
        at org.mortbay.jetty.Server.main(Server.java:401)
        ... 7 more
Caused by:
org.apache.commons.logging.LogConfigurationException:
org.apache.comm
ons.logging.LogConfigurationException: No suitable Log
constructor [Ljava.lang.C
lass;@3bc20e for
org.apache.commons.logging.impl.Log4JLogger
        at
org.apache.commons.logging.impl.LogFactoryImpl.newInst
ance(LogFactory
Impl.java:532)
        at
org.apache.commons.logging.impl.LogFactoryImpl.getInst
ance(LogFactory
Impl.java:272)
        at
org.apache.commons.logging.impl.LogFactoryImpl.getInst
ance(LogFactory
Impl.java:246)
        at org.apache.commons.logging.LogFactory.getLog
(LogFactory.java:395)
        at org.mortbay.util.JarResource.<clinit>
(JarResource.java:23)
        ... 13 more
Caused by:
org.apache.commons.logging.LogConfigurationException:
No suitable Log
 constructor [Ljava.lang.Class;@3bc20e for
org.apache.commons.logging.impl.Log4J
Logger
        at
org.apache.commons.logging.impl.LogFactoryImpl.getLog
Constructor(LogF
actoryImpl.java:432)
        at
org.apache.commons.logging.impl.LogFactoryImpl.newInst
ance(LogFactory
Impl.java:525)
        ... 17 more
Caused by: java.lang.NoClassDefFoundError:
org/apache/log4j/Logger
        at java.lang.Class.getDeclaredConstructors0
(Native Method)
        at java.lang.Class.privateGetDeclaredConstructors
(Class.java:1590)
        at java.lang.Class.getConstructor0
(Class.java:1762)
        at java.lang.Class.getConstructor(Class.java:1002)
        at
org.apache.commons.logging.impl.LogFactoryImpl.getLog
Constructor(LogF
actoryImpl.java:429)
        ... 18 more

I tracked this down to a classloader problem. Some
default jetty component seems to use the default
commons-logging mechanism to detect it's logging
facility. During this detection it seems to check the
webapplication's context class path/classloader for the
log4j classes. After detecting that log4j is present it
then seems to use a different class path/classloader to
actually load the log4j classes and fails.

----------------------------------------------------------------------

>Comment By: Greg Wilkins (gregwilkins)
Date: 2005-10-06 20:51

Message:
Logged In: YES
user_id=44062

fixed

----------------------------------------------------------------------

Comment By: Greg Wilkins (gregwilkins)
Date: 2004-04-21 21:48

Message:
Logged In: YES
user_id=44062

Thanks for this report.

log4j and commons-logging both are classloading challenges :-(

For now, can you put the log4j on the system classpath and
I will sort this out pronto.

cheers


----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=107322&aid=937718&group_id=7322


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss