Hi,
I've had a go at building a logging lib as required. However I've
realized something to do with dependencies that I think is rather important.
It's a known rule that no new classes can be added to the "javax.faces"
namespace.
Are non-javax.faces classes allowed to be bundled in the myfaces-api.jar
file? I presume not.
So in that case, any logging code that is used by the api classes would
have to be distributed in a separate jar that is a "dependency" of the
myfaces-api.jar file. But doesn't that turn the restriction above into
nonsense? What's the point of forbidding non-faces classes in
myfaces-api.jar, but allow them to be provided in a separate jar that is
a pre-requisite of myfaces-api.jar?
I've checked the sun RI, and confirmed that their "api" classes have
*no* import statements except for ones loading java.* and javax.*. This
makes their api jarfile completely "stand-alone" which I believe was the
original intent, even if the TCK doesn't currently test for that.
Unforunately, such an interpretation effectively bans any logging except
via java.util.logging - and that's banned in JSF1.1 implementations.
It is clearly still possible to log from classes in myfaces-impl.jar.
However it looks to me like logging should be excluded from the api jar,
and the emphasis placed on good exception messages instead. Where it is
desirable to emit warnings (but not throw an exception), maybe the
message could be placed in the request and logged later by some class in
the impl library.
API classes that currently do logging:
* UIComponentBase (one warning message, no exception thrown)
* FacesServlet (just trace-level enter/exit logging)
* UIComponentTag (one error message; exception thrown immediately after)
Cheers,
Simon
Martin Marinschek wrote:
Ok,
still another issue, another vote.
For the short run, Travis should go with commons-logging IMHO.
For the long run, it might be optimal to wrap away commons-logging. If
someone actually implements that, I don't see a problem with this
approach. Simon, you are volunteering, I suppose ;) ?
This is something we should do consistently across all subprojects,
though. Also for Tobago, also for the eventual Cherokee, etc. So our
fellow co-committers get a say in this as well.
regards,
Martin
On 12/15/05, Simon Kitching <[EMAIL PROTECTED]> wrote:
Martin Marinschek wrote:
-1 java.util.logging
+1 commons-logging - cause this is used right now all over the codebase.
If we want to change to use log4j directly, this would be another
issue, another vote.
I would prefer to see some myfaces logging API that would be a facade,
avoiding a compilation dependency between general MyFaces classes and
*any* external library for logging (including commons-logging).
This facade should consist of 2 classes of about 20 lines each, which
simply map directly to commons-logging. Why? Because when a container
producer wants to ship MyFaces but not commons-logging, they then just
write their own mapping to their choice of logging library and repackage
MyFaces. Two classes need to be changed, not hundreds.
Note that this is *not* duplicating commons-logging functionality (I'm a
commons-logging developer). This simply means that the MyFaces source
code doesn't contain org.apache.commons.logging references anywhere
except in the facade, localising the places where the container producer
needs to make changes. The library as shipped would still have a *hard*
runtime dependency on commons-logging, ie won't even start unless
commons-logging is in the classpath. This is different from the kind of
dependency commons-logging has on log4j/etc, and because of this the
mapping is much simpler and therefore performant.
Note; I haven't yet proved that the above is possible, though I'm fairly
confident having worked with logging libs for a long while now. This
thread has pushed me to propose the above before I'm really prepared :-)
Cheers,
Simon
