Andrea Aime a écrit :
> thinking about it, I do believe geotools is the only library I know
> of that uses the java logging directly instead of using commons-logging
> (and log4j behind it).
> 
> Still today, I do wonder how should I configure the logging subsystem,
> given that the global configuration file is simply ridicolous in my
> opinion (log configuration should be local to the current app, not centralized
> in the jdk).
> 
> Can someone point me to a sane way to configure the java logging in an 
> application
> dependent way or discuss why are we using java logging at all?
> And I would prefer something better than "because it's shipped in the jre" :-p

"Because it's shipped in the JRE" is the reason I invoked a few years ago for 
pushing 
java.util.logging against log4j. For some peoples, it is a suffisient reason 
(example: 
http://jira.jboss.com/jira/browse/JBRULES-257). Whatever this is true or not 
for Geotools may be 
subject to debate. To me, Log4J sound like one more dependency with no obvious 
benefit. But it may 
be because I don't know it well enough.

I guess that it is pretty hard to said if geotools is the only library using 
java logging directly. 
If we compare only with other Apache's libraries, this is not surprising. In 
addition, a fair amount 
of libraries are still constrained to using Java 1.3, which make Log4J the only 
choice for them.

I did a google search for "java.util.logging log4j" and found both opinions: a 
lot of peoples 
claming that log4J is way better, and some peoples claiming that common-logging 
is an application 
configuration nightmare (mostly because of tricky class loader issues if I'm 
understanding right). 
Example:

     http://www.qos.ch/logging/thinkAgain.jsp

The following article also claim that WebSphere Application Server (WAS) 6 
switched away from Log4J 
to java.util.logging:

     http://blogs.bytecode.com.au/glen/2006/04/07/1144357521557.html

Quoting the above author, not because I believe he is an authority, but just 
because I have a 
similar feeling than what he said there (except that I can't speak for 
Webshere):

     "I'm not sure java.util.logging deserves the bad wrap that it gets.
      It certainly doesn't have the prebuild flexibility of log4j with
      DailyRollingFileWithAChocolateToppingLogAppenders, but for the basics
      it does plenty (including the equivalent of a RollingFileAppender),
      and definitely hits the sweet spot for Websphere /lib/ext uses."

The following article make a comparaison between Log4J and java.util.logging. 
Their conclusion is 
similar to the above one: "Log4j and JUL are very similar APIs. They differ 
conceptually only in 
small details, and in the end do more or less the same thing, except Log4j has 
more features that 
you may or may not need."

     http://vikram.blogspot.com/2005/06/log4j-vs-javautillogging-which-is.html

If you really want all the Log4J features, then it may be worth to consider the 
following project. 
Quoting their FAQ: "x4juli is a port of the backend part of log4j. It is a full 
port, so it does not 
use wrapper classes around the backend, instead it internally extends 
java.util.logging classes.":

     http://www.x4juli.org/


As about configuring the logging in an application depends way, it depends what 
you want to do 
exactly. If you want to run two distinct applications using different loggers 
(in the sense of 
different string value in Logger.getLogger("foo") method call, where "foo" is 
usually - but not 
mandatory - the java package name), then the global configuration file allows 
you to configure 
independently at least the logging level for each of them. Example (see the few 
lines at the bottom 
of logging.properties):

    com.mycompagny.mypackage1.level = FINE
    com.mycompagny.mypackage2.level = FINER

I believe that you can also control other properties on a "by-logger" basis 
than logging level, but 
this need to be checked. Anyway, you can have more control on the programmatic 
side, e.g.:

    Logger.getLogger("org.geotools").getHandlers().<do some configuration>

The above setup logging level, formatter, filter, etc. for "org.geotools" 
logger on a system-wide 
basis, but this is not a problem if your other applications use different 
loggers, which is usually 
the case if the applications are in different packages. If you do want 
different settings for the 
same loggers, then the following article may be of some help:

     
http://www.indicthreads.com/articles/406/logging_java_logmanager_shared_hosting.html

        Martin.

-------------------------------------------------------------------------
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
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to