On Sat, Jun 6, 2009 at 08:33, Mario Ivankovits<ma...@ops.co.at> wrote: > 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.
hmm, insteresting. might be a way. there is even a ready-to-use slf4j bridge handler for JUL (http://www.slf4j.org/api/org/slf4j/bridge/SLF4JBridgeHandler.html) that does exactly the same. The downside is, you need an init call during startup of your app. > 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! Actually we would have just one single compile time dependency to the slf4j api in MyFaces (instead of the JCL dep. we have now). The rest is configuration stuff (runtime dependencies), the user deals with in his app. It just depends on the actual logging impl he wants. > 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. There are two pros of slf4j I did not mention yet: 1. parameterized messages, which make it possible to omit those ugly "if (logger.isDebugEnabled()) {..." conditions, without performance issue: see http://www.slf4j.org/faq.html#logging_performance 2. it's no longer possible to forget the log message by writing "logger.error(exc)" instead of "logger.error("an error has occured", exc)". This is because the slf4j api is strict and only allows a String (and not an Object) as first argument. However, I'm starting to like the idea of using JUL and kicking out any logging dependency (and future discussions). What I'm not sure is if the "JUL to other logging impl bridge" is multiple application friendly. What happens if the JUL root handler is replaced (thats what these bridges seem to do). Does this influence the servlet container logging and other apps as well? --Manfred > > 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 >
