logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject Re: Repository selectors, useful?
Date Fri, 28 Nov 2008 06:43:32 GMT
On 11/27/2008 12:56 PM, Ceki Gulcu wrote:
> 
> 
> Thanks for your response. Comments inline.
> 
> Jacob Kjome wrote:
>> Hi Ceki,
>>
>> Can you please explain your change of heart first?  I'll take a guess
>> as to your
>> skepticism...
> 
>> 1.  Very little built in support, making repository selectors
>> generally a custom
>> solution, which inhibits widespread use.  This can be easily addressed.
> 
> What do you mean by "very little built in support"? Do you mean in log4j
> or in application containers. If the latter, then this cannot be easily
> addressed.
> 

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".

>> 2.  The use of static loggers as well as logger abstractions such as
>> commons-logging and SLF4J (unless you use an implementation that
>> directly extends
>> SLF4J, such as Logback) break respository selectors anyway.
> 
> True.
> 

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.

>> 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."

>> 4.  A common deployment model these days is one app per/server.  In
>> this case,
>> separating logging between applications is unnecessary because there
>> is only one
>> application.
> 
> 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.

>> That said, there's plenty of evidence, based on a quick search of the
>> Log4j-user/dev mailing lists, that repository selectors are useful. 
>> In some
>> cases, they are used to separate logging by some runtime attribute,
>> such as IP
>> address or thread, not just per/application (classloader or JNDI
>> context).  As
>> such, choosing not to support the concept would disenfranchise a
>> small, but
>> nonetheless important, user base.
> 
> I agree, although the same functionality can be addressed by simpler means.
> 

And those "simpler means" are what exactly????



Jake

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


Mime
View raw message