« Return to Thread: Why our current logging approach will never work in Jetty
Re: Why our current logging approach will never work in Jetty
by sjf8
::
Rate this Message:
Opinions: you rock andrea, for fixing my bone-headed mistakes (not
checking cross-platform-ness of paths) and for doing all this gruntwork
around logging. Thanks!
Ideas: Gosh, this all seems so crazy...how does ANYONE every write a
broadly-compatible J2EE application with working logging? Are there any
use-cases of working logging setups for us to emulate?
In the end, if we go with the CommonsLogger approach, won't the
use/non-use of that jcl104-over-slf4j-1.0.1.jar not matter anyway? In
the end, our CommonsLogger will redirect to log4j, but will wind up
answering the 'Logger.isLoggable()' question based on the reading of a
config file (a bastardized log4j.properties use right now...but maybe
something else in the future?) Right?
So currently the problem is that we try to FORCE log4j and without the
use of log4j our geoserver logging control doesn't work.
After the CommonsLogger and search/replace is in-place and done, we'll
use commons-logging, and be backend agnostic. In addition we'll read
some kind of properties file to solve the "Logger.isLoggable()"
performance problem. If someone's sending commons logging to slf4j,
then that's no concern of ours really.
So the future path seems to solve this issue, no?
--saul
On Fri, 2007-10-26 at 18:48 +0200, Andrea Aime wrote:
> 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
checking cross-platform-ness of paths) and for doing all this gruntwork
around logging. Thanks!
Ideas: Gosh, this all seems so crazy...how does ANYONE every write a
broadly-compatible J2EE application with working logging? Are there any
use-cases of working logging setups for us to emulate?
In the end, if we go with the CommonsLogger approach, won't the
use/non-use of that jcl104-over-slf4j-1.0.1.jar not matter anyway? In
the end, our CommonsLogger will redirect to log4j, but will wind up
answering the 'Logger.isLoggable()' question based on the reading of a
config file (a bastardized log4j.properties use right now...but maybe
something else in the future?) Right?
So currently the problem is that we try to FORCE log4j and without the
use of log4j our geoserver logging control doesn't work.
After the CommonsLogger and search/replace is in-place and done, we'll
use commons-logging, and be backend agnostic. In addition we'll read
some kind of properties file to solve the "Logger.isLoggable()"
performance problem. If someone's sending commons logging to slf4j,
then that's no concern of ours really.
So the future path seems to solve this issue, no?
--saul
On Fri, 2007-10-26 at 18:48 +0200, Andrea Aime wrote:
> 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
« Return to Thread: Why our current logging approach will never work in Jetty
| Free embeddable forum powered by Nabble | Forum Help |
