Hi,
I'm not sure if support for java.util.logging is sufficiently advanced
yet for it to be an option.
Tomcat bundles JULI since version 5.5. JULI is a custom LogManager class
capable of separating logging by webapp. Tomcat configures JULI at
startup, so using java.util.logging calls from code running in tomcat
5.x should be ok.
However for servlet engines which don't set up a custom LogManager, the
default config in $JRE_HOME/lib/logging.properties will be used. This
will write all messages of priority INFO or higher to file ~/java%u.log,
where ~ is the home directory of the user who started the servlet
engine. A user can override the logging config for a container by setting
-Djava.util.logging.config.file=myconfig.properties
in the container startup script; however that config will apply globally
across the whole container. Only if they specify
-Djava.util.logging.manager=some.custom.logging.manager
to point to a library like JULI will they be able to have per-webapp
logging.
I also suspect, from experience as a maintainer of commons-logging. that
in order to avoid memory leaks the container must *notify* its
java.util.logging implementation when a webapp is unloaded. If I'm right
then simply setting the container startup options to point to JULI isn't
sufficient; the container actually needs to *integrate* with the
specified logging lib.
I don't know how many servlet engines come with decent java.util.logging
replacements these days. Resin? Oracle? Websphere? However the fact that
tomcat 4.x and tomcat 5.0.x don't will make things awkward for users;
essentially they will need to download and configure JULI in order to
gain any control over MyFaces logging.
Unfortunately, I can't suggest a *good* solution. I'd like to avoid
using commons-logging if possible, due to the added dependency. However
I'm not sure java.util.logging is good for the above reasons. And as
Travis says, good logging from MyFaces would help us all.
By the way, what is the minimal version of Java required to use MyFaces,
and where is that documented? I can see this which *hints* that 1.4 is
the minimum version, but nothing definitive:
http://myfaces.apache.org/compatibility.html
Cheers,
Simon
Travis Reeder wrote:
We could use java.util.logging, then no dependencies. We definitely
need some kind of logging in the components, getting a message on the
UI that says:
"Validation Error "Segment": Value is not a valid option.", isn't
exactly useful. A simple log message would have told me exactly what
the problem is. When I finally broke down and put a logger into the
component and found out in two seconds that it was because the value
wasn't in my select list after spending all day thinking it was
something completely different. For our users sake, we need this.
Travis
On 12/6/05, Simon Kitching <[EMAIL PROTECTED]> wrote:
Hi,
Is it really ok for stuff in the "api" and "impl" subdirs to depend on
commons-logging?
Does the spec say anything about dependency requirements for the JSF
implementation? In particular, I'm concerned that j2ee.jar will
apparently require a JSF implementation to be included in the future; if
MyFaces is that implementation and it uses org.apache.* libs then those
libs must also be bundled in the j2ee.jar file, or be bundled by every
container that provides that j2ee file. And exposing libraries via the
container like that can cause pain, as we all found out when a buggy
version of org.apache.xerces was bundled with java 1.4 :-(
I see that currently 3 classes in the "api" project use JCL, and lots of
classes in "impl".
JBoss and Tomcat always provide JCL jars at the container level (which
is a bad idea IMHO, but that's another topic). However not all
containers may.
Cheers,
Simon
Martin Marinschek wrote:
yes.
You can do whatever you want, as long as it is private ;)
regards,
Martin
On 12/7/05, Travis Reeder <[EMAIL PROTECTED]> wrote:
Is it safe to put loggers into Spec components, for instance in
UISelectMany, to show why something is invalid?
