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
*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
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
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
+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
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
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.
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
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
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
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
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
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
13 matches
Mail list logo
