I'm not entirely sure that e.g. tomahawk won't be included in the container.
Afaik, JBoss was thinking about bundling tomahawk with the last JBoss release - but finally didn't. regards, Martin On 12/15/05, Simon Kitching <[EMAIL PROTECTED]> wrote: > 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 > > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
