Greetings, Paolo
Monday, June 6, 2005, 1:17:38 PM, you wrote:
> You can try loading a separate configuration file for the
Java Logging
> system, like this:
> InputStream is =
> getClass().getResourceAsStream("my-logging.properties");
> LogManager.getLogManager().readConfiguration(is);> You can copy the logging.properties file from the JRE to
your favorite
> location and modify it accordingly to your needs. Obviously
you can load
> the file from wherever you like, not only from the classpath.Yes, I already tried this approach. And, as in your case, it
basically works... But I can't say I'm to happy with the
*way* it works.
Yes, I should have imagined you already tried it...
First of all, I found impossible to control logger configuration from
the config file during application runtime. Simple re-reading it
doesn't affect existing loggers in any way, so it is quite impossible
to play with loggers' levels and apply the changes without restarting
the whole bloody application container (well, I guess it *might* be
possible, but I can't figure how). It shouldn't be too hard to write
some kind of watchdog, that will periodically check modification time
of the certain file, then load/parse it and change logger's parameters
programmatically when needed. But that looks like fool's work
to me, as
log4j allows to do such things in a few simlple gestures.Again, it is obvious that JDK logging is designed to be controlled
programmatically, rather than externally via config files. That leads
to some more minor inconveniences besides the one I mentioned earlier.
I yet to have the need to change the configuration at runtime,
so I have no answers here...
The second "interesting" issue with JDK logging is the fact that
"java.util.logging.LogManager" class is in "java" namespace and,
consequently, is usually loaded by bootstrap/system classloader, which
in turn means that in normal circumstances there is only one instance
of LogManager and one logger repository per JVM. This repository can
(and usually is) be shared among multiple web applications as well as
container itself. And special care must be taken when reloading
log configuration inside each particular webapp. For example, you
may no longer count on the repository-wide threshold (.level param in
config file), as it can be as well modified by another application
just after you load your configuration. The same applies to global
handlers. So you will have to fully set up at least the root logger(s)
of your own hierarchy. That is tolerable but still somewhat limiting.BTW, I just found that with the default Tomcat configuration it is
pretty easy for you webapp to mess with loggers, defined in other
webapps as well as Tomcat's internal ones. And, of course, vice versa.
You never can't be sure of where you logging output is going, because
other webapp can attach any number of "rogue" handlers to your loggers
and capture your output. As a quick exercise, I was able to
completely shutdown logging of Tomcat itself and a number of its
applications by executing the following code inside a test webapp:Enumeration<String> list =
LogManager.getLogManager().getLoggerNames();
while (list.hasMoreElements()) {
String name = list.nextElement();
Logger.getLogger(name).setLevel(Level.OFF);
}Of course, that is usually not a real problem, as at my own machine I
have full control over the container and web applications. But, even
knowing all the above, I accidentally messed the whole
container logging
system several times after certain experiments with JDK logging
configuration file
I'm using Tomcat inside JBoss, and I put my geoserver.war inside an EAR
with what JBoss calls an "EAR scoped class loader". That means my EAR
has a separate class loader from the rest of the deployed applications,
so I believe I have a separate LogManager too, but I actually didn't
investigated this very much. The EAR scoping is quite powerful, for example
I can deploy several instances of GeoServer with different sets of JARs,
and they won't mess up each other.
From the other hand, log4j possess none of the above issues and can
be configured and controlled both in programmatic fashion and via
config files. Besides, it is much faster, then native JDK logging
framework. Though, I admit that all this is a matter of personal
taste. May be I'm just too lazyAnd simplier ways are known to
deliver less experience than tougher onesAnyway Java native
logging is not so bad, especially if you got iron nerves and angelic
patience
I'm pretty sure log4j is better then the JDK logging. I didn't compared them
personally, but I never read a single article or opinion saying the
contrary...
Also log4j is what JBoss uses, so I'd be happy if GeoServer used it. But
since
GeoTools uses JDK logging, I feel is better for GeoServer to use that too.
--
WBR,
Artie
Bye
Paolo Rizzi