users@glassfish.java.net

Error when bundling log4j - regression?

From: Vetle Roeim <vetler_at_gmail.com>
Date: Mon, 7 Mar 2011 16:33:27 +0100

Hi,

We've encountered a problem when bundling log4j with a Java EE 6
application (annotated EJBs, CDI, JPA 2 ... all the good stuff!), on
Glassfish 3.1. Unless we have log4j in the domains/domain1/lib
directory, we get the following error:

[#|2011-03-07T16:19:29.455+0100|SEVERE|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=90;_ThreadName=Thread-1;|log4j:ERROR
log4j called after unloading, see
http://logging.apache.org/log4j/1.2/faq.html#unload.|#]

[#|2011-03-07T16:19:29.455+0100|SEVERE|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=90;_ThreadName=Thread-1;|java.lang.IllegalStateException:
Class invariant violation
        at org.apache.log4j.LogManager.getLoggerRepository(LogManager.java:199)
        at org.apache.log4j.LogManager.getLogger(LogManager.java:228)
        at org.apache.log4j.Logger.getLogger(Logger.java:117)
        at no.evote.i18n.ResourceBundleControlDatabase.<clinit>(ResourceBundleControlDatabase.java:17)
        at sun.misc.Unsafe.ensureClassInitialized(Native Method)
        at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
        at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
        at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
        at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
        at java.lang.reflect.Field.get(Field.java:358)
        at org.glassfish.web.loader.WebappClassLoader.clearReferences(WebappClassLoader.java:1835)

However, at the URL specified in the error message, it says first that
it is an error in Tomcat, and that *Glassfish had a similar problem
and accepted the patch*.
Has anyone else encountered this problem?

We would preferrably like to solve it without putting log4j in the lib
directory for the domain, as this adds administrative overhead (plus,
we have our own appenders and such, so we would have to put several
other JAR files there).


Regards,
Vetle