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
