logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gulcu <lis...@qos.ch>
Subject Re: Repository selectors, useful?
Date Fri, 28 Nov 2008 09:47:20 GMT

Hello Jacob,

Comments inline.

Jacob Kjome wrote:

> Log4j 1.2.xx contains a RepositorySelector interface with no implementation and no
> well defined way of installing one.  This was addressed in Log4j 1.3 (you must
> recall, no?)... but that died on the vine.  Ideally application containers would
> support it but, like you say, that cannot be easily addressed.  Ultimately,
> application containers don't have to provide any special support for it as long as
> logging implementations provide basic support for this themselves.  So this is,
> indeed, "easily addressed" though maybe not "ideally addressed".

RepositorySelectors was a 1.3 feature? How time flies.

> And it's a feature killer.  Seems like there ought to be some way to address it?
> The repository selector is a great idea that needs to evolve into something less
> functionally fragile.

It should not be difficult to write a SLF4J binding for log4j which supports 
repository selectors.

>>> 3.  Even implementations that purport to support respository selectors
>>> fail to truly support them in practice as evidenced by the fact that Logback
>>> having been in full release for a good while - is just now being fixed to properly
>>> support them. 

>> The problem was actually in SLF4J.
> Hmmm... Except that you said "I am in the process of fixing bugs related to
> context selectors in logback."

Yes, you are right. There were minor issues in logback code as well but the 
critical bug was in SLF4J. I started looking into context selectors while fixing 
an issue filed against logback.

>> There are plenty of servers containing multiple applications. In such
>> cases, separation of logging can be accomplished by embedding a copy of
>> log4j.jar in the application itself.

> This works very well in Tomcat standalone, no matter the global server classpath,
> because of child-first classloading.  Other servers, not so much because they tend
> to use parent-first classloading.  Some have the option to use child-first.
> However, in my experience, Tomcat is the only one that reliably supports
> child-first classloading.  So, if Log4j is on the global container classpath, kiss
> per/application logging goodbye without the repository selector.  Frankly, I'm
> surprised you would make this argument since it's one that's always been available
> since well before the concept of the repository selector.  The fact that the
> repository selector concept even exists is evidence that the "simple" solution
> didn't fully meet the needs of per/application logging separation.  Mind you,
> that's not to say that the repository selector concept finally met the need.  No
> solution I've seen so far has been a panacea.

Every container has some quirk in the way it handles class loading. The servers 
I have had experience with, namely Tomcat, Jetty, Weblogic 9, JBoss and Geronimo 
all perform child first (or local first) class loading. However, the exact 
details of the class loader architecture of each server is very difficult to 
assess because each has its own quirks which sometimes change from version to 
version (of the same server). This partially explains the success of SLF4J which 
uses the dumbest binding strategy possible.

Returning to your comment, log4j does not need to be on global class container. 
If the container uses log4j (as in jboss), they can hide or not export log4j 
classes to the applications it hosts.

There is also a question of shared libraries. This is a really tough one to 
crack as mere logger contexts are insufficient.

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

To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message