Re: Why our current logging approach will never work in Jetty

> Hi,
> as you may have seen I have been playing with logging
> issues today. Many of them were related to in-classpath
> resource access and bad path construction approaches,
> but I fixed these.... yet, under our standard binary
> distribution, using Jetty, the logging configuration
> does not work at all...
>
> I investigated with sources, debugger and curses and
> in the end I found out why. The reason is that:
> a) our logging setup is convoluted
> b) there are people out there actively trying to cripple
>     any application using commons logging or log4j
>
> Our logging setup is convoluted because we do log
> with the java api, have it go thru a commons logging
> handler and finally end in log4j. And our logging level
> configuration is really in log4j.
>
> Well, turns out that Jetty ships with this little
> jcl104-over-slf4j-1.0.1.jar library. The point of this
> library is to sit in the classpath and be a 1:1
> replacement of commons logging that will redirect
> it to slf4j instead.
> So what happens when geoserver runs is that we do
> log with java logging, go thru the sl4j commons
> logging replacement, and never hit log4j.
> So all our nice configurations do not work at all.
>
> Now, our binary distribution I can fix but removing
> that jar and adding back commons logging and log4j,
> but reality is, whoever tries to deploy GeoServer
> in Jetty or another container that uses the above
> classloading trick will end up without logging
> configuration.
>
> At the moment a solution may be to have not a
> CommonLogger, but a Log4jLogger, that is, make it
> so whatever log statement we do goes directly
> into log4j so that the above jar won't cripple
> our logging setup.
> Ideally the Geotools library should allow for
> both setups, both the fall back on commons logging
> and the one on log4j, thought since commons logging
> was there to allow a chioce between java logging
> and log4j, we could probably go and code a
> Log4JLogger only.
>
> Ideas, opinions?
> Cheers
> Andrea
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@...
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> !DSPAM:4007,47221abf88351637810514!
>