Re: AW: slf4j and myfaces
here [1] you go! :) regards, gerhard [1] http://www.nabble.com/-VOTE--jul-instead-of-commons-logging-td23948865.html 2009/6/9 Mario Ivankovits > Start voting? ;-) > > > > > > *From:* Gerhard Petracek [mailto:gerhard.petra...@gmail.com] > *Sent:* Saturday, June 06, 2009 11:45 AM > *To:* MyFaces Development > *Subject:* Re: AW: slf4j and myfaces > > > > yes the -1 vote would be a veto in view of slf4j > -> no agreement -> we would vote about jul. > > or as mario suggested - let's start voting about jul. > > @mario: > yes - i'll wait until monday for sure. and we should vote a bit longer than > usual - due to holidays (+ it's an important topic for all myfaces projects) > > 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/6 Ganesh > > Hi, > > > > > we could also vote first about slf4j and everybody who prefers jul should > vote -1 > > if we don't have a majority for slf4j, we have to vote about jul. > > is that ok for everybody? > > From http://www.apache.org/foundation/voting.html my understanding of a -1 > vote is different from this. > > << Vetos > > A code-modification proposal may be stopped dead in its tracks by a -1 vote > by a qualified voter. This constitutes a veto, and it cannot be overruled > nor overridden by anyone. Vetos stand until and unless withdrawn by their > casters. > > To prevent vetos from being used capriciously, they must be accompanied by > a technical justification showing why the change is bad (opens a security > exposure, negatively affects performance, etc.). A veto without a > justification is invalid and has no weight. >> > > Better use the fraction system for voting on the logging system: > > * +0: 'I don't feel strongly about it, but I'm okey with this.' > * -0: 'I won't get in the way, but I'd rather we didn't do this.' > * -0.5: 'I don't like this idea, but I can't find any rational > justification for my feelings.' > * ++1: 'Wow! I like this! Let's do it!' > * -0.9: 'I really don't like this, but I'm not going to stand in the way > if everyone else wants to go ahead with it.' > * +0.9: 'This is a cool idea and i like it, but I don't have time/the > skills necessary to help out.' > > Best regards, > Ganesh > > >
RE: AW: slf4j and myfaces
Start voting? ;-) From: Gerhard Petracek [mailto:gerhard.petra...@gmail.com] Sent: Saturday, June 06, 2009 11:45 AM To: MyFaces Development Subject: Re: AW: slf4j and myfaces yes the -1 vote would be a veto in view of slf4j -> no agreement -> we would vote about jul. or as mario suggested - let's start voting about jul. @mario: yes - i'll wait until monday for sure. and we should vote a bit longer than usual - due to holidays (+ it's an important topic for all myfaces projects) 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/6 Ganesh mailto:gan...@j4fry.org>> Hi, > we could also vote first about slf4j and everybody who prefers jul should > vote -1 > if we don't have a majority for slf4j, we have to vote about jul. > is that ok for everybody? >From http://www.apache.org/foundation/voting.html my understanding of a -1 >vote is different from this. << Vetos A code-modification proposal may be stopped dead in its tracks by a -1 vote by a qualified voter. This constitutes a veto, and it cannot be overruled nor overridden by anyone. Vetos stand until and unless withdrawn by their casters. To prevent vetos from being used capriciously, they must be accompanied by a technical justification showing why the change is bad (opens a security exposure, negatively affects performance, etc.). A veto without a justification is invalid and has no weight. >> Better use the fraction system for voting on the logging system: * +0: 'I don't feel strongly about it, but I'm okey with this.' * -0: 'I won't get in the way, but I'd rather we didn't do this.' * -0.5: 'I don't like this idea, but I can't find any rational justification for my feelings.' * ++1: 'Wow! I like this! Let's do it!' * -0.9: 'I really don't like this, but I'm not going to stand in the way if everyone else wants to go ahead with it.' * +0.9: 'This is a cool idea and i like it, but I don't have time/the skills necessary to help out.' Best regards, Ganesh
Re: slf4j and myfaces
I second what mike said. On Sat, Jun 6, 2009 at 4:47 AM, Mike Kienenberger 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 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: AW: slf4j and myfaces
Mario Ivankovits schrieb: 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 Ok then everything is cleared up for me, then I am for JUL 100%, especially since it adds faster log handling with less locs compared to commons logging!
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 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 >
AW: slf4j and myfaces
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
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: AW: slf4j and myfaces
yes the -1 vote would be a veto in view of slf4j -> no agreement -> we would vote about jul. or as mario suggested - let's start voting about jul. @mario: yes - i'll wait until monday for sure. and we should vote a bit longer than usual - due to holidays (+ it's an important topic for all myfaces projects) 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/6 Ganesh > Hi, > > > we could also vote first about slf4j and everybody who prefers jul should > vote -1 > > if we don't have a majority for slf4j, we have to vote about jul. > > is that ok for everybody? > > From http://www.apache.org/foundation/voting.html my understanding of a -1 > vote is different from this. > > << Vetos > > A code-modification proposal may be stopped dead in its tracks by a -1 vote > by a qualified voter. This constitutes a veto, and it cannot be overruled > nor overridden by anyone. Vetos stand until and unless withdrawn by their > casters. > > To prevent vetos from being used capriciously, they must be accompanied by > a technical justification showing why the change is bad (opens a security > exposure, negatively affects performance, etc.). A veto without a > justification is invalid and has no weight. >> > > Better use the fraction system for voting on the logging system: > > * +0: 'I don't feel strongly about it, but I'm okey with this.' > * -0: 'I won't get in the way, but I'd rather we didn't do this.' > * -0.5: 'I don't like this idea, but I can't find any rational > justification for my feelings.' > * ++1: 'Wow! I like this! Let's do it!' > * -0.9: 'I really don't like this, but I'm not going to stand in the way > if everyone else wants to go ahead with it.' > * +0.9: 'This is a cool idea and i like it, but I don't have time/the > skills necessary to help out.' > > Best regards, > Ganesh > > >
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
AW: slf4j and myfaces
Hi!
> 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
http://java.sun.com/j2se/1.5.0/docs/api/java/util/logging/Logger.html
Seems that JUL support this too if we use the log() methods.
I've looked at the java source. JUL is using MessageFormat.Format then in the
formatter only if there is a placeholder in the message ({0-{4).
Not that bad.
> 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.
Funny, JUL also has no log(ex) method, just log(String, ex) (+ level for sure).
Seems the JUL API is not that bad :-)
> 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?
Seems to be true, JUL is not container friendly by default. But this needs to
be addressed by the container (and the Java Spec guys ;-) ).
It seems, this is the reason for JULI, the Tomcat logging impl.
Also JBoss solved that (as they use Tomcat ?!). See for a documentation here:
http://www.jboss.org/file-access/default/members/jbossweb/freezone/docs/latest/logging.html
They replace the LogManager by a container friendly LogManager. The JUL using
app does not need to know that.
Yeah, seems JUL can be our salvation finally ;-)
Ciao,
Mario
Re: AW: slf4j and myfaces
Hi, > we could also vote first about slf4j and everybody who prefers jul should vote -1 > if we don't have a majority for slf4j, we have to vote about jul. > is that ok for everybody? From http://www.apache.org/foundation/voting.html my understanding of a -1 vote is different from this. << Vetos A code-modification proposal may be stopped dead in its tracks by a -1 vote by a qualified voter. This constitutes a veto, and it cannot be overruled nor overridden by anyone. Vetos stand until and unless withdrawn by their casters. To prevent vetos from being used capriciously, they must be accompanied by a technical justification showing why the change is bad (opens a security exposure, negatively affects performance, etc.). A veto without a justification is invalid and has no weight. >> Better use the fraction system for voting on the logging system: * +0: 'I don't feel strongly about it, but I'm okey with this.' * -0: 'I won't get in the way, but I'd rather we didn't do this.' * -0.5: 'I don't like this idea, but I can't find any rational justification for my feelings.' * ++1: 'Wow! I like this! Let's do it!' * -0.9: 'I really don't like this, but I'm not going to stand in the way if everyone else wants to go ahead with it.' * +0.9: 'This is a cool idea and i like it, but I don't have time/the skills necessary to help out.' Best regards, Ganesh
Re: AW: 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 if we don't have a majority for slf4j, we have to vote about jul. is that ok for everybody? (i don't like the idea that every myfaces project ends up with its special logging framework dependency.) 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/6 Werner Punz > +1 for that, the issue simply is, there is a standard api, while not the > best it works good enough (since JDK5) and it is simple enough to be used > why not finally get rid of another dependency. > I am not a huge fan of dependencies in base projects anyway, so everything > which removes one gets definitely a +1 by me. > Is there any disadvantages of moving over to straight JUL? > > > Werner > > > Mario Ivankovits schrieb: > > 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 >> >> >
Re: slf4j and myfaces
On Sat, Jun 6, 2009 at 08:33, Mario Ivankovits 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 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 call
Re: AW: slf4j and myfaces
+1 for that, the issue simply is, there is a standard api, while not the best it works good enough (since JDK5) and it is simple enough to be used why not finally get rid of another dependency. I am not a huge fan of dependencies in base projects anyway, so everything which removes one gets definitely a +1 by me. Is there any disadvantages of moving over to straight JUL? Werner Mario Ivankovits schrieb: 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
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
AW: slf4j and myfaces
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 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 ex
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 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
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 > >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 > > On Fri, Jun 5, 2009 at 19:49, Mario Ivankovits 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). The
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 > On Fri, Jun 5, 2009 at 19:49, Mario Ivankovits 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 > 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 > > @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 > > > > 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 dependenc
Re: slf4j and myfaces
On Fri, Jun 5, 2009 at 19:49, Mario Ivankovits 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
AW: slf4j and myfaces
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 mailto: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 mailto: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<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 > @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 > > 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
@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 > 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 >
AW: slf4j and myfaces
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
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 Petracek 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
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
