But why not use java.util.logging then at all. There is an example [1] which shows how to reroute it to any other logging impl.
This too will remove the need of any logging dependency then. Look, with slf4j you will end with three dependencies. * the slf4j api * the commons-logging to slf4j bridge (for all the other libraries your app is going to use and which still are using commons-logging) * the slf4j impl (an since the impl itself provides nothing than the bridge, you need the logging impl to) If you are going to use java.util.logging - which is a pain to setup, but sufficient for many use-cases - these are three (up to four) dependencies too much - just for logging! I think, this will not be a bad move - and moves us completely out of line of this question once and for all I think. The java.util.logging api itself provides the same possibilities than we have today in our libraries - just different namings. Ciao, Mario [1] http://wiki.apache.org/myfaces/Trinidad_and_Common_Logging -----Ursprüngliche Nachricht----- Von: Mario Ivankovits [mailto:ma...@ops.co.at] Gesendet: Samstag, 06. Juni 2009 08:08 An: 'MyFaces Development' Betreff: AW: slf4j and myfaces Sorry, for top-posting, but Outlook makes it too hard to do it right ;-) Well, yet another configuration option for configuring our logging facade (yes, you are right, it is a facade) is for sure also not a good option. As a last note to this discussion I'd like to say, that not dealing with the class loader issue does not mean that the webapp-reloading-memory-leak has been addressed in some way. Anyway, if you think it (slf4j) is a good way to go, I'll not stand in between :-) Ciao, Mario -----Ursprüngliche Nachricht----- Von: Manfred Geiler [mailto:manfred.gei...@gmail.com] Gesendet: Freitag, 05. Juni 2009 20:50 An: MyFaces Development Betreff: Re: slf4j and myfaces 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 anfred
