[Geoserver-devel] Why our current logging approach will never work in Jetty

GeoServer GeoServer Developer
1

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

2

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

3

Andrea Aime a écrit :

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.

Given that common-logging is reputed to have classloader problems (in my
understanding Hibernate is migrating from common-loggin to SLF4J because of
that), I would be in favor of skipping common-logging. I see a choice between
two possibilities:

- SLF4JLogger (i.e. same plan using SLF4J instead of common-logging).
- Log4JLogger as suggested by Andrea

The former would allow the choice of logging frameworks other than Log4J and
java logging, but I don't know if there is a demand for that. The later may be
less prone to unexpected issues because there is one less intermediate step, and
we may also loose less informations because there is more matches for the java
logging API in Log4J than in commons-logging.

I'm fine with boths of the above approachs, at your choice.

  Martin

4

Saul Farber a écrit :

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?

In the CommonLogger (or Log4JLogger, or SLF4JLogger, or whatever) proposal, the
Logger.isLoggable() call would be redirected straight to commons-logging, or
Log4J, etc. We will not use the Java logging mechanism anymore, so there is no
need for configuration. The Log4J configuration would be the only one that matter.

  Martin

5

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

6

OK... so our logging story just seems to keep on getting worse and
worse. Maybe its just that i don't understand what is going on. I am
trying to follow all of the logging threads and getting lost.

Anyways, I guess I will just wait for an official proposal to come up
which presents the solution in a more coherent way.

-Justin

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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,47221abf88351637810514!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

7

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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

8

Justin Deoliveira a écrit :

Anyways, I guess I will just wait for an official proposal to come up
which presents the solution in a more coherent way.

It seems to me that the proposal is going in the direction of an amended version of:

http://jira.codehaus.org/browse/GEOT-1545

i.e. same than GEOT-1545, but with "commons-logging" replaced by straight calls
to Log4J. Andrea is that right?

  Martin

9

Martin Desruisseaux ha scritto:

Justin Deoliveira a écrit :

Anyways, I guess I will just wait for an official proposal to come up
which presents the solution in a more coherent way.

It seems to me that the proposal is going in the direction of an amended version of:

http://jira.codehaus.org/browse/GEOT-1545

i.e. same than GEOT-1545, but with "commons-logging" replaced by straight calls
to Log4J. Andrea is that right?

Yeah, it seems the best bet to me, considering that our log configuration is based on log4j anyways (if we don't get
to configure log4j our logging level configuration subsystem
does not work at all, right?).

Cheers
Andrea