« 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:

Reply to Author | View in Thread

Ahh, ok.  Makes sense.

Honestly, I'm fine with whatever we pick.  It seems like there's some
advantage to picking a 'meta' logging framework...be it commons-logging,
slf4j or anything else.

But if there are distinct advantages with going directly to log4j then
we certainly won't be the only folks doing that, and clearly log4j is
great.

I'm still totally flabbergasted that we can't find a coherent logging
solution that jumps RIGHT OUT at us.  Essentially we're reducing this
problem to the following:

1)  We have a .war file with lots of code in it
2)  That code wants to log messages in a configurable way
3)  We use 'isLoggable()' to choose whether or not to do expensive
calculations during logging.  isLoggable() delegates to the underlying
logging framework.

We just can't be the only people doing this.  Meh, maybe we're just
running into the 'commons-logging v. slf4j' maelstrom here.  Not our
fault!

--saul



On Fri, 2007-10-26 at 19:27 +0200, Andrea Aime wrote:

> Saul Farber ha scritto:
> > 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?
>
> I'm not aware of any, suggestions welcomed.
>
> > 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?
>
> The original concept of CommonLogger is that it would ask its
> wrapper logger about isLoggable. But since in Jetty the wrapped
> commmons logging thing we get is the slf4j replacement, our
> configuration won't enter the equation at all.
> Only the one of the actual sl4j target will, and in the case
> of Jetty, it's (oh the horror)
> http://www.slf4j.org/api/org/slf4j/impl/SimpleLogger.html
>
> If we have a Log4jLogger instead having log4j read the configuration
> file is all we need, no need to parse it in whatever way.
> Whatever we do in gt2 will end up directly in log4j hands without
> intermediations of any kind. The thing is:
>
> Logger LOGGER = Gt2LogFactory.getLogger();
> LOGGER.fine("xxx);
>
> The first statement won't return the usual java logger, but an
> implementatio of it wrapping a log4j logger directly. So java
> logging (and slf4j) should be totally out of the picture.
>
> 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


-------------------------------------------------------------------------
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