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
