Andrea Aime wrote:
Chris Holmes ha scritto:
Andrea Aime wrote:
Chris Holmes ha scritto:
Ok, I'm trying to get a handle on this issue.
One question, what's the objection to just using SFL4J ?
It seems to meet Justin's criteria of using a standard library, it'll
work with sfl4j/jetty ;) (for Andrea), and Martin likes it a lot
better than commons logging.
I imagine I just missed what the objection was, but I'm curious to
hear it.
sfl4j is just a facade like commons logging. Now, in Jetty by default
they put an implementation of the library that redirects to "simple
logging". Given that it's the first element in the classpath it'll
override whatever implementation we put in our library, meaning that
we would not be able to force log4j usage unless we manually change
the jars in the Jetty container (remember, slf4j way of doing
redirections is to implement exactly the same classes in the different
jars and have classloading decide which one gets used).
But GeoServer isn't relying on any log4g usage, right? Why would we
want to force it?
You must have lost some episodes of the logging saga :)
GeoServer is using log4j since Saul switched GeoServer to use it,
and 1.6 configures the logging levels using log4j configuration files.
So yes, either 1.6 uses log4j or it has no control on the logging levels
whatsoever.
Ah, right. Yeah, I missed that episode. Ok, just ignore me, I have
nothing productive to add :(
In the unproductive vein, however: 'this stuff sucks!' And thank you
all for doing your best to figure out a solution that works.
Chris
It's just that at the moment we're using the java logging api, which
redirects to commons logging, which redirects to log4j, and the
logging level setup is simply not working.
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/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
!DSPAM:4005,4727795931781431913854!
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard
-------------------------------------------------------------------------
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/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel