Actually, Log.setLog() still has a place, but its still a 1 shot initialization, not a repeated replacement.
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. There's also the OSGi layers out there for Jetty, those also have OSGi specific Logger impls for Jetty. Again, due to the nature of OSGi classloading, the Classloader.getResource() techniques are pointless. -- Joakim Erdfelt <[email protected]> webtide.com <http://www.webtide.com/> - intalio.com/jetty Expert advice, services and support from from the Jetty & CometD experts eclipse.org/jetty - cometd.org On Wed, Nov 27, 2013 at 8:38 AM, Lothar Kimmeringer <[email protected]>wrote: > Am 27.11.2013 15:48, schrieb Joakim Erdfelt: > > > Your technique of swapping out the Logger selection at runtime is a bug, > > not a feature. That should never have been allowed. > > I use Log.setLog(). If this is considered a bug, remove that method > immediately > or at least give it a Javadoc that explains that the there is no garantuee > that > it will do what might be the user's intention when actually setting a > Logger. > > > Regards, Lothar > > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
