Sean Schofield wrote:
We definitely don't want to overlog and we definitely want to comply
with the spec. Isn't commons logging already being used in places now
(at least tomahawk?)
Yes, commons-logging is already being used, in api (3 classes), impl
(lots) and tomahawk (lots).
IMO this is not a major dependency. Almost
every single Java application I have seen has this dependency.
Just as an aside: MyFaces is not a "Java application". It's a library.
And it's a library that J2EE servers will be bundling into their
j2ee.jar files in the near future. That makes dependencies *far* more
difficult to manage than in ordinary java applications. If MyFaces
requires commons-logging 1.0.4, and some library used by a webapp
requires commons-logging 1.1.0, then that's a critical problem. However
this is really not relevant as commons-logging-1.1.0 *will* be binary
compatible when released.
Maybe we could switch to JDK 1.4 logging at some future point. Again,
an argument for not overlogging (less stuff to switch later!)
I personally like log4j and commons logging and I haven't bothered to
use JDK 1.4 logging. Its just a preference and laziness on my part.
As Jesse notes, java.util.logging can't be used in JSF1.1. But for
future reference:
java.util.logging should be regarded as two parts: an API and a basic
implementation. The API for the Logger class (which is all we care
about) is fine.
The default implementation, however, is completely unsuitable for use in
a servlet container or j2ee container. Tomcat 5.5 fixes this by bundling
an alternative implementation. I'm concerned that other containers may
not yet do this, in which case having MyFaces write to java.util.logging
will cause major headaches. See my earlier response for more details:
http://mail-archives.apache.org/mod_mbox/myfaces-dev/200512.mbox/[EMAIL
PROTECTED]
-----Original Message-----
From: Jesse Alexander (KBSA 21)
Sent: Wednesday, December 07, 2005 7:53 PM
To: MyFaces Development
Subject: RE: Loggers in API Components
As soon as a JSF-1.1-implementation uses a JDK 1.4 (and above) feature
(as jdk-logging) this implementation will be flagged as non-complieant.
Therefor we have a use-case against java.util.logging.
As it seems, it is less of an issue if a javax.faces.* class has a
runtime
dependency (eg. to commons-logging).
Ok, if the spec allows a javax.faces.* package to have a dependency on
org.apache.commons, then I'm +1 on using commons-logging for MyFaces 1.1.
Whether java.util.logging is appropriate for MyFaces 1.2.x depends upon
proving that all containers that MyFaces will be deployed in provide
proper non-default java.util.logging implementations.
-----Original Message-----
From: Travis Reeder [mailto:[EMAIL PROTECTED]
I'm pretty sure logging is the last thing we'll have to look at for
performance, there are many other things that will need to be
optimized first.
+1
Commons-logging has always kept an eye on performance. It's not going to
be a bottleneck; in fact its performance impact is not likely to be even
measurable.
We can always optimize later
when people are comfortable using MyFaces and one form of comfort is
knowing why things aren't working. Sean has a good point, that logging
can be a good differentiator, Tapestry stands out as a good example.
The only major performance issue is when the message being logged is
built by concatenating strings, eg:
log.debug(
"problem " + problemName
+ " occurred at time " + new Date());
There's a convention to handle this:
if (log.isDebugEnabled()) {
log.debug(....)
}
There's also a project around somewhere that post-processes .class files
to wrap all logging calls in the appropriate if-statement, keeping the
source code cleaner. I can't find the project URL for the moment.
Note that performance is not really relevant if a problem *is* being
logged. If DEBUG is enabled, then performance isn't critical. And if
there are vast numbers of ERROR messages being logged, then the user has
more serious problems than a performance hit!
I'm +1 for java.util.logging, I really don't know why people think
log4j is so much better, maybe someone can fill me in?
As described above:
* java.util.logging Logger class API: ok
* rest of java.util.logging API: flawed according to many people
* default implementation of java.util.logging: deliberately minimal;
simply not suited for use in container frameworks.
On 12/7/05, Abrams, Howard A <[EMAIL PROTECTED]> wrote:
My concern would be that things will get out of hand and we'll do so
much logging that it will affect performance in a noticeable way. We
should find a way to "compile-out" some of the logging for
production
use before "logging everthing".
As described above, logging will *not* cause any significant performance
hit. Even vast amounts of logging calls will not be measurable when the
associated logging level is disabled, as long as the simple pattern
described above is used.
On 12/7/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
Our wiki currently reads:
http://wiki.apache.org/myfaces/MyFaces_Developer_Notes
===============================
Logging
Except in the JSF API (javax.faces.*) classes, where there must
not
be
any dependencies to additional libraries, commons-logging is
used
for
logging generally. Commons-logging should be used in the
recommended
way, i.e. each class has it's own private static logger.
There are two interesting points here:
(1)
is a runtime dependency from javax.faces.* on org.apache.commons allowed?
(2)
Having static logger instances is actually *not* safe when a library is
deployed in a "shared" directory, and per-webapp logging configuration
files are being used.
The problem with logging from classes in a "shared" classpath is that
they can either write to a "shared" logging destination, or write to a
per-webapp logging destination.
Writing to a shared one can be ok when testing is occurring, and the
tester is running a private container with only the webapp under test.
However in a situation where a production system has a container (eg
jboss) running half-a-dozen production apps, and wants to turn up
logging to detect a problem with one app things get really ugly if there
is only one shared logging config file, and one logging output shared
across all webapps deployed in the container. Even when logging is only
set up to output ERRORs, having a single shared logging file is not very
nice. It's hard to tell which webapp generated an error message. Note
that jboss do provide a log4j filter which can separate out stuff on a
per-webapp basis, though at a fair performance hit.
Having separate logs per webapp seems much nicer. When the class doing
the logging is inside the webapp, that's easy: when it creates its
static logger, it uses the context classloader to obtain a logger
pointing to its local config. This is slow, but done only once per
classload so that's ok.
However when the class is in a "shared" path, there are two ugly choices:
* on each call to the logger, get the context classloader to
determine which underlying logger to really use
* just do this lookup when the Logger is created, not when it is
used.
The first option above is simply unacceptable for performance reasons.
The second is therefore used by commons-logging.
The second, however, means that if the logger is *static* then it
attaches to the logging configuration of whatever webapp *first* called
it. Thereafter, other webapps that call it get their logging output sent
to the logfile of the first webapp. VERY BAD.
The only known solution to this currently is: when a library may be
deployed in a "shared" classpath, do *not* use static loggers. Instead,
make the logger a non-static member on the class. The logger is,
unfortunately, created once for each instance of the class, instead of
once when the class is loaded, but it's the least-worst option.
Sorry if this rambles a bit. I don't currently have the time to write
this as elegantly as I would like.
Regards,
Simon
(committer: commons-logging; contributor: log4j)
