geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gulcu <>
Subject Re: SLF4J in geronimo
Date Sat, 29 Nov 2008 11:30:35 GMT

David Jencks wrote:
> On Nov 27, 2008, at 9:05 AM, Ceki Gulcu wrote:
>> Thus, it seems to me that Geronimo is keeping one instance of SLF4J
>> classes for its own use and another instance for the applications it
>> hosts. Is my hypothesis correct?
> Geronimo is not doing this intentionally.  I don't know why this would 
> be happening.  If you can figure out I'd like to know why.
> One thing to note is that if you are starting geronimo via gshell 2 vms 
> are starting -- one for gshell, and one for geronimo.  I think the 
> gsh-classworlds.conf file is only affecting the gshell classpath, not 
> the geronimo classpath.
> Normally the procedure for upgrading jars is explained here:  
> However I believe the slf4j classes are loaded extremely early so 
> logging is available during most of server startup so this procedure may 
> not work for them.
> One sure way to get the classes you want is to change the slf4j version 
> in the root pom and build your own geronimo snapshot.
> Could I ask what you are investigating?
Hi David,

I am starting geronimo using the 'start-server' server script which
later invokes the 'gsh' script which than launches a JVM using

So, it appears that I was unknowingly launching gshell.

Thank you for link to the "how-to-upgrade-jars-and-swap-modules" page.

I am trying to solve the old "logging separation" problem, described
in [1].

In the simplest case, the logging separation problem can be solved by
placing a cop of slf4j+binding jars within application. Easy as
pie. However, under certain circumstances, a copy of slf4j+binding
jars are already present *or* must be present on shared class
path. The former case occurs when the server itself uses slf4j (as in
geronimo or jetty). Jetty's class loader hides SLF4J to the class
loader of hosted applications. See [2] for details.

Let me digress for the length of the next paragraph.

In the case of Tomcat 5.x, commons-logging.jar is present on the
shared class path, and due to the dynamic nature of commons-logging,
causing leakage of commons-logging loggers into web-applications using
commons-logging and embedding their own copy of commons-logging
jars. This leakage impedes proper garbage collection of stopped
web-applications. Tomcat 6.x does suffer from this problem because it
relies on "org.apache.juli", a commons-logging clone, for logging. The
fact that o.a.juli resides in a different package avoids leakage of
tomcat's loggers into the web-app, unless application developers also
start using "org.apache.juli" in their web-apps.

Coming back to SLF4J, even if the container does not use SLF4J, if
shared libraries residing on a shared class path relies on SLF4J,
SLF4J jar must be brought up to the level of the shared class path.

Thus, there are circumstances where SLF4J jars must be present on the
shared class path. In order to avoid mixing logs between various
hosted applications, we must have a way of separating logging
environments event if the SLF4J classes are loaded only once in memory
in the whole JVM. Enter "context selectors" (in logback) and
"repository selectors" in log4j.

So, to answer your question, I was investigating the behavior of
logback context selectors in Geronimo, in particular the
ContextJNDISelector. However, I did not get very far because there are
too many pieces missing in my understanding of Geronimo, in particular
its class loading model. Nevertheless, I think we should collaborate
on the logging separation problem so as to be prepared when users come
knocking on our respective doors.

We could also declare victory, now.

Assuming that "application class loader"+-- in Geronimo follow the me-first
(aka child-first) delegation model, and if applications embed their
own copy of slf4j+binding jars within the application, then their
logging environment will be unaffected by Geronimo. (They will load
their own copy of SLF4J+binding classes into memory). Ignoring the
problem of logging in shared libraries, we could declare that there is
no problem instead of being bogged down in the logging quagmire. Note
that under the same scenario, JCL's dynamic binding model suffers from leakages.

"Application class loader" is the class loader used to load a particular hosted 
applications. Typically, application class loader is a child of the class loader 
used by Gerinomo to load its own classes.

Note /snapshot/ in the URL indicating that the URL is only temporary.


Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.

View raw message