Re: [jetty-users] Why are Loggers static members in classes

[Lothar Kimmeringer <job@xxxxxxxxxxxxxx>]

Am 27.11.2013 17:20, schrieb Joakim Erdfelt:
> Actually, Log.setLog() still has a place, but its still a 1
> shot initialization, not a repeated replacement.

I don't do it repeated times, that was just an example what the
effect of using static members is.

> Because, there is a sliver of time between the startup of the JVM
> (with real logging frameworks) and the initialization of Jetty
> where Log.setLog() makes sense to connect the real logger with
> the implementation that Jetty should use.
> 
> This is used in many embedded scenarios, even Android! (yes, there's
> an Android ADB Logging impl for Jetty's Logger
> <https://code.google.com/p/i-jetty/source/browse/trunk/i-jetty/i-jetty-server/src/main/java/org/mortbay/ijetty/log/AndroidLog.java>)
> For environments like Android, loading the configuration from a
> properties file via Classloader.getResource() isn't really possible.

And my point in this whole discussion is that Log.setLog doesn't work
if one of the classes that should use this new logger was already loaded.
Be it with an import-statement in a class or because one of your own
classes is deriving from a Jetty-class. Since the static constructor
of - say - AbstractLifeCyle was already executed, all messages that
are logged by that class land in the original logger and not the one
you set with setLog.

I appreciate all the tips you gave me, how I can solve my current problem
in my testcase (learned a lot that way) but if Log.setLog is still supposed
to fulfill a function, the issue I have, should still be addressed.

As I said. When I find the time, I will come up with concrete examples.
Maybe then my point will be more clear (english isn't my main language
so I might lack the ability to explain it in a better way). And source
is always better than descriptions anyway ;-) But that will take until
next week at the moment.


Regards, Lothar