as we saw in previous discussions there are several different opinions. we really discussed that topic a lot. (i also don't really like the idea of having a myfaces logging facade which does more or less the same as other solutions... as mentioned before i thought mario was talking about something different (a mechanism i already had a look at it and won't work due to the mentioned problem...))
anyway, i don't like to have the next big discussion about this topic without a final vote... imo we should just vote about using slf4j as soon as possible for all myfaces projects (from now on). as mentioned: only for projects which use an external logging framework (so e.g. trinidad isn't affected right now). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2009/6/5 Gerhard Petracek <gerhard.petra...@gmail.com> > >JCL and slf4j ARE ready-to-use logging wrappers. > > +1 > > regards, > gerhard > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > > 2009/6/5 Manfred Geiler <manfred.gei...@gmail.com> > > On Fri, Jun 5, 2009 at 19:49, Mario Ivankovits <ma...@ops.co.at> wrote: >> > Hi! >> > >> > Could one please eloberate a little bit more in detail what the pros are >> of >> > slf4j? >> >> Pros: >> No class loader ambiguousness (as you mentioned) >> You get what you define (especially when using maven): >> compile-dependency to slf4j-api >> runtime-dependency to slf4j-adapter of YOUR choice >> --> that's it! >> >> No wild guessing like with JCL: Use Log4j if it is anywhere in the >> (web container) classpath, else use Java logging... What, if I want to >> use Java logging although there is Log4j in the classpath?! >> "Someone dropped a log4j.jar in the tomcat/lib folder. Oh no, not >> again..." >> Yes, I know commons-logging.properties solves this, but that's >> awful... (BTW, I hate properties files in the root package namespace!) >> >> >> > Notice, I switched to it in our company project - but always using the >> > commons-logging api and just used the slf4j-over-cl wrapper. This is >> > something wich is possible for each and ever user of myfaces already, >> just >> > by adjusting the depencendcies correctly. >> >> Guess, you meant the jcl-over-slf4j.jar bridge, right? That's the part >> that reroutes JCL calls to the slf4j API. >> Yes, that is a possible solution, but keep in mind that this is kind >> of a hack. It is actually a reimplementation of the JCL API >> (namespace) that routes all calls to SLF4J. >> It's meant as runtime solution for legacy libs. Using it as compile >> time dependency might be a shortcut, but my feeling says it's not the >> nicest solution. >> >> >> > Lately I even switched to my own logging wrapper, but this is another >> story. >> > In the end, everything still uses the cl API which is proven to work >> fine. >> > (I created the org.apache.commons.logging package structure with my own >> > classes - which for sure is not possible for myfaces!). >> >> yet another logging wrapper.... WHY do so many people feel they must >> write such a thing? JCL and slf4j ARE ready-to-use logging wrappers. >> So??? >> >> >> > I still think, that using the cl api is the best we can do for our >> users. If >> > they then use cl as implementation - and if this is considered "good" - >> is >> > another story, but nothing WE should anticipate. >> >> They CAN use JCL if myfaces uses slf4j. They just define a >> slf4j-jcl-x.x.x.jar runtime-dependency and everything is fine. >> >> >> > As far as I can say the cl api is rock solid, just the class-loader >> stuff is >> > a pain. But (again AFAIK), slf4j does not solve it, it just does not >> deal >> > with it. >> >> slf4j DOES solve the problem by avoiding highly sophisticated classloader >> magic! >> >> >> > Before we start using any other logging api I'd suggest to build our own >> > thin myfaces-logging wrapper where one then can easily plug in log4j, >> cl, >> > jul (java utils ogging) or whatever - we do not even have to provide any >> > other impl than for jul. >> >> yet another logging wrapper... (see above) >> >> How would you implement such a pluggable wrapper? Yet another >> (mandatory) config parameter. System property? Servlet context param? >> Come on! >> What about this: looking for existing well-known logging >> implementations and define some priority rules... Dejavu. See the >> problem? >> >> >> > As a plus, this then will remove a dependency - a dependency to any >> logging >> > framework - which - in terms of dependencies can be considered as a >> "good" >> > thing, no? >> >> You buy this "good" thing by re-implementing SLF4J and/or JCL. >> Serious. I cannot imagine a "wrapper" (actually a "facade", right?) >> implementation that is versatile for the developers and pluggable for >> the users and has less source code than any of the well-known logging >> facade APIs (slf4j and jcl). They both are actually meant to heal the >> java world from proprietary "yet another logging facades/wrappers"! >> >> >> +1 for using SLF4J as logging facade for future MyFaces developments >> (JSF 2.0, ...) >> +0 for replacing JCL by SLF4J for all existing code (if someone is >> volunteering to do the job I have no problem with that...) >> >> >> --Manfred >> > >
