Hi,
I'm playing with geoerver exception reporting
and it really seems log4jformatter is eating
all exceptions stack traces we do have... now,
that's bad in my opionion, makes debugging
issues much harder.
Why has it been designed this way?
Cheers
Andrea
Andrea Aime ha scritto:
Hi,
I'm playing with geoerver exception reporting
and it really seems log4jformatter is eating
all exceptions stack traces we do have... now,
that's bad in my opionion, makes debugging
issues much harder.
Ah, more feedback. Just removed the LOG4JFormatter
initialization from GeoServer.initLogging(...) and
now logs are much more informative, althought more
verbose too, and they contain exceptions we can really
use to help users...
Cheers
Andrea
Andrea Aime wrote:
Andrea Aime ha scritto:
Hi,
I'm playing with geoerver exception reporting
and it really seems log4jformatter is eating
all exceptions stack traces we do have... now,
that's bad in my opionion, makes debugging
issues much harder.Ah, more feedback. Just removed the LOG4JFormatter
initialization from GeoServer.initLogging(...) and
now logs are much more informative, althought more
verbose too, and they contain exceptions we can really
use to help users...
Yeah, logging's a bit of a mess. The LOG4Jformatter gives us some decent control over how things are done, but at the expense of picking up the normal java logging settings. I didn't realize it was eating exceptions though, I think that's the first I've heard of that.
I think that if you remove that initialization then setting the logging level in the admin console may no longer work... But I may be wrong about that.
Chris
Cheers
Andrea-------------------------------------------------------------------------
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,456170c3240491365099012!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Chris Holmes ha scritto:
Andrea Aime wrote:
Andrea Aime ha scritto:
Hi,
I'm playing with geoerver exception reporting
and it really seems log4jformatter is eating
all exceptions stack traces we do have... now,
that's bad in my opionion, makes debugging
issues much harder.Ah, more feedback. Just removed the LOG4JFormatter
initialization from GeoServer.initLogging(...) and
now logs are much more informative, althought more
verbose too, and they contain exceptions we can really
use to help users...Yeah, logging's a bit of a mess. The LOG4Jformatter gives us some decent control over how things are done, but at the expense of picking up the normal java logging settings. I didn't realize it was eating exceptions though, I think that's the first I've heard of that.
Well, the error is in fact in the Lo4jFormatter base class, that does
the msg formatting. It does the fancy thing of trying to provide a localized error message and totally forgets about the stack trace.
I think that if you remove that initialization then setting the logging level in the admin console may no longer work... But I may be wrong about that.
Indeed you're right. But we can't ship geoserver like this, you already
have seen on sigma that error tracking becomes way too difficult.
We could avoid the Log4jformatter and move the code that changes the
logging level into GeoServer thought.
Cheers
Andrea