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
]
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
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
.
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
+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
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
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
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
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
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
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
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
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
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
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
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
, 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
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
:* 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
-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
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
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
, 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
- 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
27 matches
Mail list logo
