Hi,
I don't see that this is such an issue for tobago/tomahawk/cherokee.
None of those components will be bundled in the container, so if one of
those libs requires a particular helper library, then the webapp
deployer can just deploy that library at the webapp level.
It's when a j2ee.jar starts dictating to the container vendor what
libraries the container vendor must deploy that things get sensitive...
But yes I will try to create a logging facade as I described below, for
evaluation.
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
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
