You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Jacob Kjome <ho...@visi.com> on 2008/11/27 19:36:11 UTC
Re: Repository selectors, useful?
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.
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.
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.
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.
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.
Jake
On 12/26/2008 7:05 AM, Ceki Gulcu wrote:
>
> Hello,
>
> I am in the process of fixing bugs related to context selectors in logback.
> Context selectors are the equivalent of repository selectors in log4j.
> However,
> while few years back I thought that context selectors, aka repository
> selectors,
> were the wave of the future, I am increasingly skeptical about their
> usefulness.
>
> If you are using context/repository selectors, could you please explain
> why?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Repository selectors, useful?
Posted by Ceki Gulcu <ce...@qos.ch>.
Jacob Kjome wrote:
> How so? Of course the libraries must use non-static loggers, but what else
> prevents shared libraries from participating in a logger context where the logging
> implementation exists in the same (or parent) classloader?
Most libraries use static loggers. It would be nice if they used non-static
loggers but they don't. When loggers are non-static, then loggers need to be
serializable which is not the case in all frameworks, e.g. log4j.
My main point is that repository selectors offer a fragile solution to a very
complex problem. Today, many applications embed a copy of the logging framework
of their choice, which seems to work overall. IMHO, using repository selectors
requires too much expertise.
> You still haven't detailed your alternative solution the logger separation
> problem. If you have one, please detail. Saying over and over that there other
> other ways to separate application logging without the repository selector
> concept, but never describing what they are, is not particularily convincing. If
> there really are alternate, and better, ways of separating logging I'm prepared to
> drop repository selectors in a heartbeat. But forgive me if I remain skeptical.
Skeptical is OK. The approach has been fleetingly mentioned on the logback-user
mailing list in the "Context selectors useful?" thread [1]. However, I'll let
you know when we have a concrete solution.
[1] http://www.qos.ch/pipermail/logback-user/2008-November/date.html
> Jake
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Repository selectors, useful?
Posted by Jacob Kjome <ho...@visi.com>.
On 11/28/2008 3:47 AM, Ceki Gulcu wrote:
>
> 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.
>
Seriously? Ok, moving right along then...
>> 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.
>
...which would require Log4j to directly implement the SLF4J interfaces, no?
Doubtful for 1.2.xx.
>>>> 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.
So, you're saying that certain new containers have sophisticated classloaders
(OSGi I'm guessing?) that separate the server libraries from the application
libraries. That's very handy and something I haven't experienced for myself yet.
My company uses Weblogic 8.1 update 6 and 9.1, neither of which has such
sophisticated classloading behavior (that I'm aware of). All of what you've been
saying so far seems to rely either on bleeding edge functionality or
not-yet-existent functionality.
>
> There is also a question of shared libraries. This is a really tough one
> to crack as mere logger contexts are insufficient.
>
How so? Of course the libraries must use non-static loggers, but what else
prevents shared libraries from participating in a logger context where the logging
implementation exists in the same (or parent) classloader?
You still haven't detailed your alternative solution the logger separation
problem. If you have one, please detail. Saying over and over that there other
other ways to separate application logging without the repository selector
concept, but never describing what they are, is not particularily convincing. If
there really are alternate, and better, ways of separating logging I'm prepared to
drop repository selectors in a heartbeat. But forgive me if I remain skeptical.
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Repository selectors, useful?
Posted by Ceki Gulcu <li...@qos.ch>.
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.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Repository selectors, useful?
Posted by Jacob Kjome <ho...@visi.com>.
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
Re: Repository selectors, useful?
Posted by Ceki Gulcu <li...@qos.ch>.
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.
> 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.
> 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.
> 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.
> 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.
> Jake
>
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org