Re: slf4j and myfaces
Gerhard Petracek schrieb: hello all, again the logging-framework topic :) there were several discussions about it and i'm not aware of an agreement. udo wrote [1]: replace commons-logging with slf4j as i know we agreed on using one logging framework dependency for all myfaces projects. if i remember correctly, most of us prefer slf4j. - i suggest to vote about using slf4j in all myfaces projects. (at least if a project is using an external logging framework.) regards, gerhard [1] http://www.nabble.com/Re%3A-Trinidad-vs-Tobago-p23884581.html Ok here is another suggestion, for myfaces 1.2+ we have to be on JDK5, right? So why dont we simply move over to the Sun logging API? One dependency less is always welcome! Werner
Re: slf4j and myfaces
On Sat, Jun 6, 2009 at 08:33, Mario Ivankovitsma...@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
Re: slf4j and myfaces
that would be possible as well. i just started with slf4j since we already discussed it and udo wrote about the switch to slf4j in the next release... we could also vote first about slf4j and everybody who prefers jul should vote -1 Just wait until Monday if possible, then enough developers should have commented on the thread already. Probably it is clear then already that a vote for JUL is enough. (i don't like the idea that every myfaces project ends up with its special logging framework dependency.) Yes, thats true. Ciao, Mario
Re: slf4j and myfaces
Mario Ivankovits schrieb: that would be possible as well. i just started with slf4j since we already discussed it and udo wrote about the switch to slf4j in the next release... we could also vote first about slf4j and everybody who prefers jul should vote -1 Just wait until Monday if possible, then enough developers should have commented on the thread already. Probably it is clear then already that a vote for JUL is enough. (i don't like the idea that every myfaces project ends up with its special logging framework dependency.) Yes, thats true. Ciao, Mario The only downside I see is that we might break compatibility for java 1.4 since JUL gut some overhaul between 1.4 and 5, but on the other hand is it really important anymore? Which projects still have to be on 1.4
Re: slf4j and myfaces
I'd strongly prefer to see JUL instead of something else (including JCL) now that it's part of the standard. In Ganesh-speak, +0.9 JUL, -0.9 slf4j On Sat, Jun 6, 2009 at 6:37 AM, Mario Ivankovits ma...@ops.co.at wrote: Hi! The only downside I see is that we might break compatibility for java 1.4 since JUL gut some overhaul between 1.4 and 5, but on the other hand is it really important anymore? Which projects still have to be on 1.4 In 1.4.2 the log methods in question were already there. So - as a logging user only - this might not be a problem. http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/Logger.html Ciao, Mario
Re: slf4j and myfaces
I second what mike said. On Sat, Jun 6, 2009 at 4:47 AM, Mike Kienenbergermkien...@gmail.com wrote: I'd strongly prefer to see JUL instead of something else (including JCL) now that it's part of the standard. In Ganesh-speak, +0.9 JUL, -0.9 slf4j On Sat, Jun 6, 2009 at 6:37 AM, Mario Ivankovits ma...@ops.co.at wrote: Hi! The only downside I see is that we might break compatibility for java 1.4 since JUL gut some overhaul between 1.4 and 5, but on the other hand is it really important anymore? Which projects still have to be on 1.4 In 1.4.2 the log methods in question were already there. So - as a logging user only - this might not be a problem. http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/Logger.html Ciao, Mario -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: slf4j and myfaces
yep, Trinidad uses its own and I am not entirely sure if it is easy to replace... (the logger is sorta wrapper/facade for the standard logger) On Fri, Jun 5, 2009 at 8:18 AM, Gerhard Petracekgerhard.petra...@gmail.com wrote: hello all, again the logging-framework topic :) there were several discussions about it and i'm not aware of an agreement. udo wrote [1]: replace commons-logging with slf4j as i know we agreed on using one logging framework dependency for all myfaces projects. if i remember correctly, most of us prefer slf4j. - i suggest to vote about using slf4j in all myfaces projects. (at least if a project is using an external logging framework.) regards, gerhard [1] http://www.nabble.com/Re%3A-Trinidad-vs-Tobago-p23884581.html -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: slf4j and myfaces
@matthias: yes - that's the reason for my comment: ...external logging framework... @udo: imo we should discuss the logging topic before we have a release which already uses slf4j - especially the suggestion of mario sounds interesting. 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 Mario Ivankovits ma...@ops.co.at Hi! Could one please eloberate a little bit more in detail what the pros are of slf4j? 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. 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!). 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. 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. 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. 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? Ciao, Mario *Von:* Gerhard Petracek [mailto:gerhard.petra...@gmail.com] *Gesendet:* Freitag, 05. Juni 2009 17:18 *An:* MyFaces Development *Betreff:* slf4j and myfaces hello all, again the logging-framework topic :) there were several discussions about it and i'm not aware of an agreement. udo wrote [1]: replace commons-logging with slf4j as i know we agreed on using one logging framework dependency for all myfaces projects. if i remember correctly, most of us prefer slf4j. - i suggest to vote about using slf4j in all myfaces projects. (at least if a project is using an external logging framework.) regards, gerhard [1] http://www.nabble.com/Re%3A-Trinidad-vs-Tobago-p23884581.html
Re: slf4j and myfaces
@mario: which logging frameworks would be supported by such a wrapper. i can just mention that there are logging frameworks out there which internally force an exception and statically use entry x of the call hierarchy - so such a wrapper would lead to wrong logging information. regards, gerhard (after reformulating the previous mail quite quickly the text wasn't perfect - but i think you know what i mean...) 2009/6/5 Gerhard Petracek gerhard.petra...@gmail.com @matthias: yes - that's the reason for my comment: ...external logging framework... @udo: imo we should discuss the logging topic before we have a release which already uses slf4j - especially the suggestion of mario sounds interesting. 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 Mario Ivankovits ma...@ops.co.at Hi! Could one please eloberate a little bit more in detail what the pros are of slf4j? 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. 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!). 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. 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. 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. 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? Ciao, Mario *Von:* Gerhard Petracek [mailto:gerhard.petra...@gmail.com] *Gesendet:* Freitag, 05. Juni 2009 17:18 *An:* MyFaces Development *Betreff:* slf4j and myfaces hello all, again the logging-framework topic :) there were several discussions about it and i'm not aware of an agreement. udo wrote [1]: replace commons-logging with slf4j as i know we agreed on using one logging framework dependency for all myfaces projects. if i remember correctly, most of us prefer slf4j. - i suggest to vote about using slf4j in all myfaces projects. (at least if a project is using an external logging framework.) regards, gerhard [1] http://www.nabble.com/Re%3A-Trinidad-vs-Tobago-p23884581.html
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
Re: slf4j and myfaces
ok - i thought you mean something different... i didn't thought that you mean something like: I know, we end up having a slf4j within myfaces do you mean to have a wrapper e.g. as commons-module [1]? - every myfaces project has a dependency to it? regards, gerhard [1] http://svn.apache.org/repos/asf/myfaces/commons/trunk/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2009/6/5 Mario Ivankovits ma...@ops.co.at Why? I think our wrapper can do pretty much the same than slf4j does. Having a public static Log log = LogFactory.getLog(MyClass.class) can easily be supported by our logging framework. Then, any known logging framework has the most possible information available, whatever it does with it. If a logging framework use a static position of the stack trace, to gather its information, is bound to fail anyway and has to be considered a bad implementation, no? AFAIK, in terms of cl class loader issues, having a static log ist not bad if the logging facade has been loaded with the same class-loader than the library were loaded. Which should always be the case with our own wrapper. Yes, I know, we end up having a slf4j within myfaces. But I see no point having a dependency to such a simple API - which exactly adds no value, but forces every cl user to setup the sfl4j-over-cl bridge. IMHO, the java way to do it is to provide our own simple logging wrapper, by using jul as default impl. I know that jul sucks, but this then can easily be customized by the developer. Mojarra also uses jul, no? So good or bad, this i something we have to deal with anyway - providing a pluggable logging api is fair enough then. I think, most of the time the user will not care and just start using jul. Too bad that SUN did not manage to provide a logging api which has been widely accepted :-( Ciao, Mario *Von:* Gerhard Petracek [mailto:gerhard.petra...@gmail.com] *Gesendet:* Freitag, 05. Juni 2009 20:22 *An:* MyFaces Development *Betreff:* Re: slf4j and myfaces @mario: which logging frameworks would be supported by such a wrapper. i can just mention that there are logging frameworks out there which internally force an exception and statically use entry x of the call hierarchy - so such a wrapper would lead to wrong logging information. regards, gerhard (after reformulating the previous mail quite quickly the text wasn't perfect - but i think you know what i mean...) 2009/6/5 Gerhard Petracek gerhard.petra...@gmail.com @matthias: yes - that's the reason for my comment: ...external logging framework... @udo: imo we should discuss the logging topic before we have a release which already uses slf4j - especially the suggestion of mario sounds interesting. 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 Mario Ivankovits ma...@ops.co.at Hi! Could one please eloberate a little bit more in detail what the pros are of slf4j? 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. 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!). 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. 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. 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. 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? Ciao, Mario *Von:* Gerhard Petracek [mailto:gerhard.petra...@gmail.com] *Gesendet:* Freitag, 05. Juni 2009 17:18 *An:* MyFaces Development *Betreff:* slf4j and myfaces hello all, again the logging-framework topic :) there were several discussions about it and i'm not aware of an agreement. udo wrote [1]: replace commons-logging with slf4j as i know we agreed on using one logging framework dependency for all myfaces projects. if i remember
Re: slf4j and myfaces
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
Re: slf4j and myfaces
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,
