cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorg Heymans ...@domek.be>
Subject [M10N] JCL and webapp classloader issues
Date Wed, 11 Jan 2006 14:20:20 GMT
I am trying to get the webapp to work again now that the jetty folks
kindly produced new snapshots for us. Good news is they are keen to
support us getting our core running :

> Jan Bartel wrote:
> 
> ... Snapshot is on it's way to the repository now. A beta release 
> will also follow shortly. Let us know if there is anything else we
> can do to help Cocoon on it's way.


Now about the webapp:
---------------------

IMPORTANT : "mvn war:inplace" never removes dependencies in WEB-INF/lib.
So if you remove/upgrade a lib and you'ld like to test the webapp then
you should remove WEB-INF/lib before war:inplace to start from a clean
state.


Trying mvn jetty6:run in cocoon-webapp i get :

Caused by: org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: No suitable Log
constructor [Ljava.lang.Class;@c7c7bc for
org.apache.commons.logging.impl.Log4JLogger
        at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:532)
        at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:272)
        at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:414)
        at net.sf.ehcache.CacheManager.<clinit>(CacheManager.java:86)
        ... 44 more
Caused by: org.apache.commons.logging.LogConfigurationException: No
suitable Log constructor [Ljava.lang.Class;@c7c7bc for
org.apache.commons.logging.impl.Log4JLogger
        at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:432)
        at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:525)
        ... 47 more
Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger
        at java.lang.Class.getDeclaredConstructors0(Native Method)
        at java.lang.Class.privateGetDeclaredConstructors(Class.java:1618)
        at java.lang.Class.getConstructor0(Class.java:1930)
        at java.lang.Class.getConstructor(Class.java:1027)
        at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:429)


... which is a classloader issue AFAICT.


Reading Ceki Gülcü's trashing of commons-logging [1], i'm wondering if
we have other options as to what our usage of JCL is concerned (slf4j
[2] ?).

I'm by no means an expert on classloaders and logging , but Ceki's
wording at the end is clear enough for everyone to understand :

> As demonstrated above, JCL's discovery mechanism invents new and
> original ways of shooting yourself in the foot. For example, with JCL
> you can shoot yourself in the foot while aiming at the sky. Thanks to
> JCL you can be hit by lightning in the middle of the desert when it's
> not raining. If your computing life is too dull and trouble is what
> you are looking for, then JCL is the way to go.


Thoughts? (has this been hashed over before?)


Jorg

[1] http://www.qos.ch/logging/classloader.jsp
[2] http://www.slf4j.org/


Mime
View raw message