On Jun 22, 2009, at 5:09 PM, Kevin Brown wrote:
Putting aside our deployment scenario for now, do you have any
thoughts
specifically about the logging questions?
I don't have any strong opinions on the matter. I have never
encountered a
situation where java.util.logging was inadequate. The performance
kind of
sucks due to excessive synchronization, but the API itself doesn't
seem bad
enough to bother with an external dependency.
Unfortunately, we have encountered situations where JUL is inadequate.
The problem isn't so much the API, but the configuration. It probably
isn't an issue for centralized websites or software-as-a-service types
of deployments, where you have complete control over the deployment
environment, but it can be for packaged software that people expect to
be able to just download and throw in an app server with a minimum of
initial configuration. The java.util.logging framework seems to have
been designed with only server administrators in mind, without
offering any control over the initial configuration to application
developers.
So there are a few solutions that I can think of.
Ideally, I'd prefer it if Shindig used slf4j. It's pretty lightweight
and very flexible, and can easily be configured to log straight
through to java.util.logging. It also has some nice API conveniences,
such as message format strings that allow you to avoid string
concatenation for messages that won't get logged at the currently
configured level without having to wrap an if statement around it. It
has a nice MIT-style license.
But I can understand why you might not want to add an additional
dependency. Another option is Apache Commons Logging. This is of
course pretty common in Apache projects, and is already pulled into
Shindig transitively by several other libraries, so it wouldn't mean
adding a new dependency.
I see that Shindig used to be inconsistent about use of Commons
Logging vs. JUL (https://issues.apache.org/jira/browse/SHINDIG-940)
and that the decision was to standardize on JUL. I found some
discussion in the list archives (http://markmail.org/thread/54bvh2jfjacr52ph
) and it sounds like a number of people prefer JUL, but it's not clear
why. I know that commons logging has some known class loader issues,
but those aren't hard to work around, and wouldn't affect the way
Shindig itself is written. Also, slf4j provides a drop-in commons-
logging replacement JAR that could be used by anyone that wants to
avoid them entirely. In any case, JUL also has class loader issues of
its own (e.g., http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java)
.
If you really want to stick with JUL, another solution is to allow
logger construction to be overridden. If we could hook into the way
that Logger objects are created, then we could reconfigure the
handlers it uses. Unfortunately, AFAICT, loggers created through
Logger.getLogger(String) don't provide a way to do that. So it would
require adding a LoggerFactory interface to Shindig that is injected
by Guice. This is related to what Henning suggested in https://issues.apache.org/jira/browse/SHINDIG-259
but not quite the same; I'm not suggesting a wrapper interface
around the Logger as a whole, just a factory to abstract its
construction. The default implementation could just call
Logger.getLogger but integrators could replace that with their own
implementation if they need to.
If any of these sound OK, I'm happy to provide the patch for whatever
approach everyone can agree on. We're going to have to do one of these
changes on our vendor branch regardless, but I'd really like to avoid
diverging from the mainline any more than necessary.
Cheers,
-- Tim
