>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 >
