[Geoserver-devel] GeoserverDataDirectory.jav fix, org.springframework logging setup

Farber_Saul_EEA · July 31, 2006, 9:40pm

I applied the previously mentioned fix to GeoserverDataDirectory.java. Should fix 'GEOSERVER_DATA_DIR' users on trunk.

This bug was hard to find because it wasn't getting logged. It occurred during the spring application auto-wiring phase, before geoserver initializes itself and programmatically sets up log4j logging. (in GeoServer.java, geoserver sets up log4j logging appenders/levels which send specific packages log messages to stdout).

So I couldn't actually *see* the problem...and any other problem such as this (a mis-configured spring config file, noclassdeffounderrors during spring startup, etc.) would also be invisible. Frustratingly, they simply fail silently in tomcat.

In the end, I wound up getting an error trace by putting log4j.properties on the classpath of the webapp. Which made me wonder why it lives where it currently lives:
geoserver-trunk/web/src/main/webapp/WEB-INF/log4j.properties

It doesn't get picked up by the log4j configurator automatically (it's not on the classpath) and it's not referenced (as far as I could search) by any file in geoserver itself. Is it 'vestigal' or something?

Anyway, in 1.3.x this wasn't a big deal. There just wasn't a whole lot that happened between startup and GeoServer.java's calls to setup logging for org.geotools and org.vfny. However now there's a whole lot of awesome spring auto-wiring stuff that happens between web-app launch by the container, and the GeoServer.java calls to set up log4j logging.

I propose that we move the file "log4j.properties" to
geoserver-trunk/main/src/main/java/log4j.properties. That way it will wind up in the WEB-INF/classes directory when you do a '$mvn install' and will get picked up by the log4j configurator when the first log4j messages come from inside spring.

I also propose that the log4j.properties file makes everything pretty 'quiet' by setting logging levels to WARN or higher (lower?).

As far as I've tested, this doesn't conflict with the programmatic log4j logging that gets handled inside GeoServer.java...it just lets spring/tomcat tell you more about what's going on inside spring/tomcat while its starting up.

Thoughts?

--saul

Farber_Saul_EEA · July 31, 2006, 9:54pm

Oops, I meant

geoserver-trunk/web/src/main/java/log4j.properties.

As I wrote belowe, log4j.properties would wind up inside the
main-<verision>.jar artifact. That wouldn't do anyone any good.

--saul

I propose that we move the file "log4j.properties" to
geoserver-trunk/main/src/main/java/log4j.properties. That way it will wind up in the WEB-INF/classes directory when you do a '$mvn install' and will get picked up by the log4j configurator when the first log4j messages come from inside spring.

Chris_Holmes1 · July 31, 2006, 9:57pm

Yeah, that sounds good.

Our logging situation is pretty confused, I would like to get it a bit better in some way. The real log4j stuff is not used at all. One jar was requiring it, but we don't even use it any more.

I think the reason it's left in is because it actually makes some of the other logging more quiet - or at least I vaguely remember removing it once and being overwhelmed by logging messages in what should be the GeoServer output.

Note that in GeoServer.java, we're not actually setting log4j stuff, what we're doing is making an output format for java logging that _looks_ like log4j, since Rob, the original geoserver developer, liked how it looked better when geotools moved to java logging.

It'd be nice if we had a better logging story in GeoServer - I'm not quite sure how to get there though. It's really nice to let users set logging levels through the web admin, but also nice to not over ride other defaults.

Chris

Saul Farber wrote:

I applied the previously mentioned fix to GeoserverDataDirectory.java. Should fix 'GEOSERVER_DATA_DIR' users on trunk.

This bug was hard to find because it wasn't getting logged. It occurred during the spring application auto-wiring phase, before geoserver initializes itself and programmatically sets up log4j logging. (in GeoServer.java, geoserver sets up log4j logging appenders/levels which send specific packages log messages to stdout).

So I couldn't actually *see* the problem...and any other problem such as this (a mis-configured spring config file, noclassdeffounderrors during spring startup, etc.) would also be invisible. Frustratingly, they simply fail silently in tomcat.

In the end, I wound up getting an error trace by putting log4j.properties on the classpath of the webapp. Which made me wonder why it lives where it currently lives:
geoserver-trunk/web/src/main/webapp/WEB-INF/log4j.properties

It doesn't get picked up by the log4j configurator automatically (it's not on the classpath) and it's not referenced (as far as I could search) by any file in geoserver itself. Is it 'vestigal' or something?

Anyway, in 1.3.x this wasn't a big deal. There just wasn't a whole lot that happened between startup and GeoServer.java's calls to setup logging for org.geotools and org.vfny. However now there's a whole lot of awesome spring auto-wiring stuff that happens between web-app launch by the container, and the GeoServer.java calls to set up log4j logging.

I propose that we move the file "log4j.properties" to
geoserver-trunk/main/src/main/java/log4j.properties. That way it will wind up in the WEB-INF/classes directory when you do a '$mvn install' and will get picked up by the log4j configurator when the first log4j messages come from inside spring.

I also propose that the log4j.properties file makes everything pretty 'quiet' by setting logging levels to WARN or higher (lower?).

As far as I've tested, this doesn't conflict with the programmatic log4j logging that gets handled inside GeoServer.java...it just lets spring/tomcat tell you more about what's going on inside spring/tomcat while its starting up.

Thoughts?

--saul

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1003,44ce7947101111804284693!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Justin_Deoliveira · July 31, 2006, 10:16pm

Great work Saul.

I am sorry to say that logging in GeoServer is a mess. Logging was something on my list of things to clean up but I never got around to it.

You can also specify a location in teh web.xml file of the application. This is why the file was in WEB-INF/. However the current web.xml does not have this, I beleive this was somethign that was lost in the merge process, because I know it was there at one point.

Anyways, what it looks like this is this:

<listener>
<listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
</listener>

But it seems easier to just throw the log configuration file into src/main/java as you say. So I am all for it!

-Justin

Saul Farber wrote:

I applied the previously mentioned fix to GeoserverDataDirectory.java. Should fix 'GEOSERVER_DATA_DIR' users on trunk.

This bug was hard to find because it wasn't getting logged. It occurred during the spring application auto-wiring phase, before geoserver initializes itself and programmatically sets up log4j logging. (in GeoServer.java, geoserver sets up log4j logging appenders/levels which send specific packages log messages to stdout).

So I couldn't actually *see* the problem...and any other problem such as this (a mis-configured spring config file, noclassdeffounderrors during spring startup, etc.) would also be invisible. Frustratingly, they simply fail silently in tomcat.

In the end, I wound up getting an error trace by putting log4j.properties on the classpath of the webapp. Which made me wonder why it lives where it currently lives:
geoserver-trunk/web/src/main/webapp/WEB-INF/log4j.properties

It doesn't get picked up by the log4j configurator automatically (it's not on the classpath) and it's not referenced (as far as I could search) by any file in geoserver itself. Is it 'vestigal' or something?

Anyway, in 1.3.x this wasn't a big deal. There just wasn't a whole lot that happened between startup and GeoServer.java's calls to setup logging for org.geotools and org.vfny. However now there's a whole lot of awesome spring auto-wiring stuff that happens between web-app launch by the container, and the GeoServer.java calls to set up log4j logging.

I propose that we move the file "log4j.properties" to
geoserver-trunk/main/src/main/java/log4j.properties. That way it will wind up in the WEB-INF/classes directory when you do a '$mvn install' and will get picked up by the log4j configurator when the first log4j messages come from inside spring.

I also propose that the log4j.properties file makes everything pretty 'quiet' by setting logging levels to WARN or higher (lower?).

As far as I've tested, this doesn't conflict with the programmatic log4j logging that gets handled inside GeoServer.java...it just lets spring/tomcat tell you more about what's going on inside spring/tomcat while its starting up.

Thoughts?

--saul

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1004,44ce7947101151995013331!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Farber_Saul_EEA · July 31, 2006, 10:21pm

Actually, I think I've found an even easier way.

At this page it talks about how spring does its internal logging:

http://forum.springframework.org/showpost.php?p=9324&postcount=2

The link on that page (to http://jakarta.apache.org/commons/logging/guide.html#Configuration) has some great info on how to get jakarta-commons logging to redirect to JDK14 logging (also known as java.util.log).

So I just stuck a file called "commons-logging.properties" with the instruction to have commons-logging log to Jdk14 and now spring looks just like the rest of tomcat.

Now there's no need for log4j at all, so I removed that file entirely.

One fewer logging system seems good to me.

Also, chris's comment about having a custom formatter for geoserver was a good point. I *like* the geoserver formatting MUCH MUCH better than the default java logging stuff. Although it seems like that should be configurable somewhere.

Anyway, I'll commit all this stuff.

--saul

But it seems easier to just throw the log configuration file into src/main/java as you say. So I am all for it!