I agree with sebb. I prefer an organization where everyone gets one
vote. This is obviously not the only way an organization can run, but
I like neither having a diminished or overwhelming power with my vote.
The best part of having only +1 is that you can't use your merit to
strong-arm decisions o
On 11 August 2011 10:21, Ceki Gülcü wrote:
> On 11/08/2011 8:13 AM, Henri Yandell wrote:
>
>
>> I was going to say: "That would put Sebb in charge of the ASF!!!", but
>> then I noticed that after the import of Jena Andy Seaborne appears to
>> be the top count committer (I know, that doesn't measur
On 11/08/2011 8:13 AM, Henri Yandell wrote:
I was going to say: "That would put Sebb in charge of the ASF!!!", but
then I noticed that after the import of Jena Andy Seaborne appears to
be the top count committer (I know, that doesn't measure size of
commit). [http://svnsearch.org/svnsearch/rep
On Wed, Aug 10, 2011 at 6:06 AM, Ceki Gülcü wrote:
> On 10/08/2011 8:02 AM, Henri Yandell wrote:
>
>
>
> Thank you for posting this summary of the Apache way. Yes, it is damn
> hard to track contributions, especially if one wishes to do it
> accurately and fairly. However, it is possible and even
strub
--- On Wed, 8/10/11, Christian Grobmeier wrote:
> From: Christian Grobmeier
> Subject: Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
> To: "Commons Developers List"
> Date: Wednesday, August 10, 2011, 1:47 PM
> > Thank you for posting this
On 10/08/2011 3:59 PM, Gary Gregory wrote:
"Creating a branch of commons-digester using SLF4J/jul/log4jv2 will
not convince anyone."
I am sorry, but deciding for other people what they are going to think
is no way to go either.
Experimenting by branching is leading by example. This is a good
o
On 10/08/2011 3:47 PM, Christian Grobmeier wrote:
So, why do you want to measure my coding efficiency? Not even my Boss
(if I would have one) is allowed to do that! Commit points measure my
coding skills probably, not my human skills.
Commit points as described in my blog measure the number of
On Wed, Aug 10, 2011 at 9:06 AM, Ceki Gülcü wrote:
> On 10/08/2011 8:02 AM, Henri Yandell wrote:
>>
>> On Tue, Aug 9, 2011 at 10:16 AM, Ceki Gulcu wrote:
>>
>>> * On the ASF model
>>>
>>> In a nutshell, while the ASF is a great organization in many ways, it
>>> is not a meritocracy mainly because
> Thank you for posting this summary of the Apache way. Yes, it is damn
> hard to track contributions, especially if one wishes to do it
> accurately and fairly. However, it is possible and even easy to keep
> *approximate* track of contributions, e.g. via "commit points" as
> described in my commi
On 10/08/2011 8:02 AM, Henri Yandell wrote:
On Tue, Aug 9, 2011 at 10:16 AM, Ceki Gulcu wrote:
* On the ASF model
In a nutshell, while the ASF is a great organization in many ways, it
is not a meritocracy mainly because merit is not measured at all and
at the project level no responsiblity is
+1 as well. That's the path I advocated for Configuration 2.0, combined
with the log4j bridge from Paul Smith [1]
Maybe we should stop spending our energy on alternative logging
frameworks and try to improve the standard one in the JDK instead. I
have been told that Java was open source now, s
On Tue, Aug 9, 2011 at 10:16 AM, Ceki Gulcu wrote:
> * On the ASF model
>
> In a nutshell, while the ASF is a great organization in many ways, it
> is not a meritocracy mainly because merit is not measured at all and
> at the project level no responsiblity is accrued on merit beyond
> committersh
Hi all guys!!!
sorry for joining so late the discussion (working on some stuff as
bricklayer at home!!! didn't know it is fun!)
* I don't understand why JULI should be so "complicated" to be
adopted... if in trouble, please take a look at juli-to-log4j[1] bride
written by our ASF mate Paul Smith
On 09.08.2011 11:57, Christian Grobmeier wrote:
Another option is to try to work with Ceki to address some of the
concerns of the commons community with regards to using slf4j.
* There is a hassle with too many jars for dependencies with slf4j.
* Every time Ceki goes on vacation everything stops
On Tue, Aug 9, 2011 at 5:57 AM, Christian Grobmeier wrote:
>>> Another option is to try to work with Ceki to address some of the
>>> concerns of the commons community with regards to using slf4j.
>>>
>>> * There is a hassle with too many jars for dependencies with slf4j.
>>> * Every time Ceki goes
>> Another option is to try to work with Ceki to address some of the
>> concerns of the commons community with regards to using slf4j.
>>
>> * There is a hassle with too many jars for dependencies with slf4j.
>> * Every time Ceki goes on vacation everything stops.
>> * Some have a preference for Ap
A few comments on the list of points against slf4j below...
On 08/08/2011 05:58 PM, Elijah Zupancic wrote:
> From what I can tell from the thread, here are the following points
> against SLF4J:
>
> * Log4j developer V2 would like to see the Apache community support
> the project rather than puttin
On Mon, Aug 8, 2011 at 5:58 PM, Elijah Zupancic wrote:
>
> Another option is to try to work with Ceki to address some of the
> concerns of the commons community with regards to using slf4j.
>
> * There is a hassle with too many jars for dependencies with slf4j.
> * Every time Ceki goes on vacation
OK. Note that -- in a similar vein to what you proposed -- I'm also
fine with simply keeping commons-logging as is. The really nice thing
about commons-logging is that it is based on an API (like SLF4j but
unlike jul!).
Therefore, it is really easy for people to do whatever they want --
e.g. for p
Raman,
You may have proposed this earlier in the thread and I didn't catch
it. I actually like your suggestion the best, but it seems like it is
a difficult sell for a lot of people to compile against the slf4j API
for a variety of reasons that are not strictly code related.
My suggestion was int
On 08/08/2011 04:56 PM, Elijah Zupancic wrote:
> This could be done by choosing (dynamically or by configuration) the
> logger implementation log4j / commons / slf4j / jul and then loading
> the LoggerFactory into a wrapper class that is then called used by the
> Commons project.
>
> We would then
> The biggest issue I have with SLF4J is figuring out the dependencies
> that I need. I really detest having an API jar and then an
> implementation/bridge jar. I find that too annoying.
I cannot see how that is annoying. It's simple and it works.
What's annoying you about this?
-
I agree with this sentiment. In the last 3 years all of the large
commercial projects that I have worked on used slf4j just for the very
reason that I needed to bridge the logging implementations in multiple
third-party libraries.
While reading this thread, one approach occurs to me that hasn't be
On 08/08/2011 03:28 PM, Matt Benson wrote:
> On Mon, Aug 8, 2011 at 2:23 PM, Paul Benedict wrote:
>> On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta wrote:
>>> Perhaps I'm missing something, but what exactly is wrong with simply
>>> using slf4j? It is an extremely simple, widely used library that
>>>
On Mon, Aug 8, 2011 at 3:28 PM, Matt Benson wrote:
> On Mon, Aug 8, 2011 at 2:23 PM, Paul Benedict wrote:
>> On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta wrote:
>>> Perhaps I'm missing something, but what exactly is wrong with simply
>>> using slf4j? It is an extremely simple, widely used library
On Mon, Aug 8, 2011 at 3:23 PM, Paul Benedict wrote:
> On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta wrote:
>> Perhaps I'm missing something, but what exactly is wrong with simply
>> using slf4j? It is an extremely simple, widely used library that
>> provides out of the box hooks for many logging f
On Mon, Aug 8, 2011 at 2:23 PM, Paul Benedict wrote:
> On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta wrote:
>> Perhaps I'm missing something, but what exactly is wrong with simply
>> using slf4j? It is an extremely simple, widely used library that
>> provides out of the box hooks for many logging f
On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta wrote:
> Perhaps I'm missing something, but what exactly is wrong with simply
> using slf4j? It is an extremely simple, widely used library that
> provides out of the box hooks for many logging frameworks including
> log4j and logback, simple to configur
On 08/08/2011 02:00 PM, ralph.goers @dslextreme.com wrote:
> On Mon, Aug 8, 2011 at 8:06 AM, Simone Tripodi
> wrote:
If we really have to reconsider this stuff, then I'd propose to
a) Use java.util.logging, because it doesn't require any additional
dependencies and is guarantee
I'm not a fan of this plan. Have you actually tried to "bridge" jul to
anything? While it will work anywhere that doesn't imply it will work
properly.
Ralph
On Mon, Aug 8, 2011 at 8:06 AM, Simone Tripodi wrote:
> Hi all,
>
> >>
> >> If we really have to reconsider this stuff, then I'd propose t
Hi all,
>>
>> If we really have to reconsider this stuff, then I'd propose to
>>
>> a) Use java.util.logging, because it doesn't require any additional
>> dependencies and is guaranteed to work anywhere.
>> b) Carefully document how to bridge jul to log4j, because that's
>> exactly what's required
ark Thomas
> Subject: Re: [logging] logging vs slf4j
> To: "Commons Developers List"
> Date: Sunday, August 7, 2011, 9:57 AM
> On 07/08/2011 09:31, Jochen Wiedmann
> wrote:
> > On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory
> wrote:
> >
> >> Or m
2011/8/7 Mark Thomas :
> On 07/08/2011 09:31, Jochen Wiedmann wrote:
>> On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory wrote:
>>
>>> Or maybe Log4j 2 could replace [logging].
>>
>> If we really have to reconsider this stuff, then I'd propose to
>>
>> a) Use java.util.logging, because it doesn't requ
On 07/08/2011 09:31, Jochen Wiedmann wrote:
> On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory wrote:
>
>> Or maybe Log4j 2 could replace [logging].
>
> If we really have to reconsider this stuff, then I'd propose to
>
> a) Use java.util.logging, because it doesn't require any additional
> dependen
On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory wrote:
> Or maybe Log4j 2 could replace [logging].
If we really have to reconsider this stuff, then I'd propose to
a) Use java.util.logging, because it doesn't require any additional
dependencies and is guaranteed to work anywhere.
b) Carefully docum
On Fri, Aug 5, 2011 at 4:07 PM, Gary Gregory wrote:
> On Aug 5, 2011, at 16:27, Phil Steitz wrote:
>
>> On 8/5/11 12:53 PM, Henri Yandell wrote:
>>> HttpComponents would be SFL4j in my structure. They definitely need
>>> debugging.
>>>
>>> Lang or Codec don't.
>>>
>>> If I had to generalize, I'd
On Aug 5, 2011, at 16:27, Phil Steitz wrote:
> On 8/5/11 12:53 PM, Henri Yandell wrote:
>> HttpComponents would be SFL4j in my structure. They definitely need
>> debugging.
>>
>> Lang or Codec don't.
>>
>> If I had to generalize, I'd say it's because HttpComponents is not at
>> the bottom of its
On 05/08/2011 9:53 PM, Henri Yandell wrote:
It's a set of decisions you have to make - what I'm advocating (with
'if you can help it') is to ask yourself "do I need logging?" rather
than "how can I add logging?". I think a lot is added due to the
latter approach.
+1
Hen
--
Ceki
-
On 8/5/11 12:53 PM, Henri Yandell wrote:
> HttpComponents would be SFL4j in my structure. They definitely need debugging.
>
> Lang or Codec don't.
>
> If I had to generalize, I'd say it's because HttpComponents is not at
> the bottom of its stack. You need to know what the communication is
> betwee
HttpComponents would be SFL4j in my structure. They definitely need debugging.
Lang or Codec don't.
If I had to generalize, I'd say it's because HttpComponents is not at
the bottom of its stack. You need to know what the communication is
between HttpComponents and the API below it (ie) a http con
On Fri, Aug 5, 2011 at 8:59 AM, Gary Gregory wrote:
> On Fri, Aug 5, 2011 at 8:23 AM, Bill Speirs wrote:
>> IMO, saying "Don't do logging in a library" seems like a bad rule.
>>
>> The HTTPComponents client has logging and it has been VERY helpful to be
>> able to turn on debug logging and see wh
On Fri, Aug 5, 2011 at 8:23 AM, Bill Speirs wrote:
> IMO, saying "Don't do logging in a library" seems like a bad rule.
>
> The HTTPComponents client has logging and it has been VERY helpful to be
> able to turn on debug logging and see what requests and responses are going
> over the wire. Yes, I
IMO, saying "Don't do logging in a library" seems like a bad rule.
The HTTPComponents client has logging and it has been VERY helpful to be
able to turn on debug logging and see what requests and responses are going
over the wire. Yes, I could fire up Wireshark and get the same info, but
turning o
Well said Hen, big +1 :)
>
> B) If you are an app, use log4j.
or logback, depending on the cases, IMHO
>
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Aug 5, 2011 at 8:18 AM, Henri Yandell wrote:
> On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory wrote:
>> On Wed,
On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory wrote:
> On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict wrote:
>> I prefer Apache driven projects when possible. If LOG4J2 takes off,
>> feature requests would be implemented quicker, I hope.
>
> I like Log4J just fine thank you very much :)
>
> I'm lo
2011/8/4 Ralph Goers
> The flaw would be in JBoss Portal, not the portlet spec. The spec doesn't
> have anything to do with logging.
>
In fact I would have said "a library in general" that is referenced both in
the portal application and in portlets.
Anyway you're right, if JBPortal would have s
The flaw would be in JBoss Portal, not the portlet spec. The spec doesn't have
anything to do with logging.
Ralph
On Aug 3, 2011, at 11:18 AM, Antonio Petrelli wrote:
> 2011/8/3 Antonio Petrelli
>
>> However in my experience SLF4J has a big drawback: when used in a shared
>> classloader (JBos
2011/8/3 Antonio Petrelli
> However in my experience SLF4J has a big drawback: when used in a shared
> classloader (JBoss Portal anyone?) it is needed to have the same stinky old
> version of SLF4J in all applications during compile time, and the library
> should be excluded from the package.
>
Hi Ceki
2011/8/3 Ceki Gülcü
> Antonio Petrelli wrote:
> On the other hand, the version of slf4j binding that you select at
> runtime needs to match the slf4j-api. For example, if you have
> slf4j-api-1.6.1.jar on your classpath and you wish to use log4j, then
> you need slf4j-log4j12-1.6.1.jar o
Antonio Petrelli wrote:
> However in my experience SLF4J has a big drawback: when used in a
> shared classloader (JBoss Portal anyone?) it is needed to have the
> same stinky old version of SLF4J in all applications during compile
> time, and the library should be excluded from the package.
Hell
Paul,
> BTW, in terms of swelling community development, if LOG4J+JCL were to
> merge and just become JCL2, it could have the visibility of all
> Commons committers. Isn't it much more of a common component than a
> separate project? I think the logging project is dysfunctional anyway
> -- make it
First of all, sorry to jump in at this point of the discussion.
2011/7/28 Simone Tripodi
> Hi all guys,
> I remember I raw a thread - not sure if I did it here at commons or
> somewhere else here at apache - where specified we prefer adding
> [logging] as components dependency instead of slf4j..
On Wed, Aug 3, 2011 at 9:51 AM, Gary Gregory wrote:
>
> I like Log4J just fine thank you very much :)
>
> I'm looking forward to 2.0.
>
> Gary
>
I concur with Gary. All my apps use LOG4J, not JCL or SLF4J. My
dependencies do, however, but LOG4J works great minus a few
enhancements I'd like to see
On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict wrote:
> I prefer Apache driven projects when possible. If LOG4J2 takes off,
> feature requests would be implemented quicker, I hope.
I like Log4J just fine thank you very much :)
I'm looking forward to 2.0.
Gary
>
> On Wed, Aug 3, 2011 at 9:27 AM
I prefer Apache driven projects when possible. If LOG4J2 takes off,
feature requests would be implemented quicker, I hope.
On Wed, Aug 3, 2011 at 9:27 AM, Ralph Goers wrote:
>
> On Aug 3, 2011, at 6:07 AM, David Karlsen wrote:
>
>> Hasn't the time for both CL and log4j passed by? The trend nowada
On Aug 3, 2011, at 6:07 AM, David Karlsen wrote:
> Hasn't the time for both CL and log4j passed by? The trend nowadays seems to
> be slf4j/logback.
If you read further back in this thread you will see where I highlighted the
problems in Logback as well as difficulties with SLF4J. Plus, every ti
Hasn't the time for both CL and log4j passed by? The trend nowadays seems to
be slf4j/logback.
Den 3. aug. 2011 15:03 skrev "Gary Gregory"
følgende:
> Or maybe Log4j 2 could replace [logging].
>
> Gary
>
> On Wed, Aug 3, 2011 at 5:33 AM, Stephen Colebourne
wrote:
>> My thought is that there might
Or maybe Log4j 2 could replace [logging].
Gary
On Wed, Aug 3, 2011 at 5:33 AM, Stephen Colebourne wrote:
> My thought is that there might be some java.util.logging helpers that
> could be written, and perhaps they might go in [lang] if there are 5
> or fewer classes.
>
> I assume that slf4j and
My thought is that there might be some java.util.logging helpers that
could be written, and perhaps they might go in [lang] if there are 5
or fewer classes.
I assume that slf4j and log4j have their own j.u.logging connections,
so that end is dealt with.
The time of [logging] has probably passed.
On Tue, Aug 2, 2011 at 1:59 AM, Emmanuel Bourg wrote:
> Le 28/07/2011 22:01, Henri Yandell a écrit :
>>
>> Personally I'm happy for commons-logging to die. :)
>
> Yeah let's use java.util.logging instead :)
Primarily that I don't get the feeling we have a major community of
developers on c-loggin
Le 28/07/2011 22:01, Henri Yandell a écrit :
Personally I'm happy for commons-logging to die. :)
Yeah let's use java.util.logging instead :)
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For addi
plugin/
--- On Fri, 7/29/11, Ralph Goers wrote:
> From: Ralph Goers
> Subject: Re: [logging] logging vs slf4j
> To: "Commons Developers List"
> Date: Friday, July 29, 2011, 5:39 PM
> Unfortunately, you are in the
> minority on this one. Technically, you could just
The major issue I had was https://issues.apache.org/jira/browse/LOG4J2-31. We
currently use SLF4J for audit logging via the SLF4J extension's EventLogger and
EventData. Unfortunately, SLF4J has to convert the EventData object to XML
since SLF4J/Logback don't provide a good way of handling this.
Commons Logging takes a least common denominator approach, which makes it
useful for only fairly simple use cases. The goals for Log4J 2 are much more
extensive than just a simple API that wraps other logging frameworks.
Ralph
On Jul 29, 2011, at 6:19 AM, Paul Benedict wrote:
> Would there
Unfortunately, you are in the minority on this one. Technically, you could just
use the Log4J 2.0 Impl jar, but then you would be coding to a private API.
Ralph
On Jul 29, 2011, at 8:15 AM, Gary Gregory wrote:
> One thing that is a hassle to me with modularized projects, even
> slf4j, is that y
One thing that is a hassle to me with modularized projects, even
slf4j, is that you end up with a bunch of tiny jars. IOW & IMO: a
mess. Personally, I want one jar to rule them all. If I want to switch
logging implementer or a client wants another impl I have to fiddle
with my builds and explain wh
Would there be any merit in combining the log4j and commons logging
code? Given a hypothetical Log4j 2 and JCL 2, how much different could
they really be in terms of their goals and add-ins?
On Fri, Jul 29, 2011 at 4:51 AM, Gilles Sadowski
wrote:
> Hello.
>
>> I would have done that but some of t
Hello.
> I would have done that but some of the deficiencies are in the API and I
> couldn't get Ceki to incorporate them.
Do you have a pointer to a listing of those deficiencies?
> [...]
Thanks,
Gilles
-
To unsubscribe, e-
On Fri, Jul 29, 2011 at 10:33 AM, Torsten Curdt wrote:
> At some stage I started to refactor commons logging into a multi
> module maven project and got rid of the discovery part. So you would
> have the commons-logging-api jar plus exactly one of the
> implementation bridges. So you pick the logg
At some stage I started to refactor commons logging into a multi
module maven project and got rid of the discovery part. So you would
have the commons-logging-api jar plus exactly one of the
implementation bridges. So you pick the logging target by putting the
correct bridge into your classpath. Si
great news Ralph, and kudos for your hard work!
looking forward to hear more from log4j soon!
have a nice day, all the best,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Jul 29, 2011 at 5:53 AM, Ralph Goers wrote:
> Oh - I should have also mentioned that I imple
Oh - I should have also mentioned that I implemented support for the SLF4J API
and commons logging as well as the new Log4J API.
Ralph
On Jul 28, 2011, at 7:30 PM, Henri Yandell wrote:
> Random input. Seems to me you should focus on making Log4J the impl
> excellent and not trying to create yet
I would have done that but some of the deficiencies are in the API and I
couldn't get Ceki to incorporate them. Unfortunately, SLF4J and Logback are run
under the BDFL model, not a collaboration as is done at the ASF.
Ralph
On Jul 28, 2011, at 7:30 PM, Henri Yandell wrote:
> Random input. Seem
Random input. Seems to me you should focus on making Log4J the impl
excellent and not trying to create yet.another.facade. ie) Don't
compete with SLF4J, compete with Logback (given its licensing).
Hen
On Thu, Jul 28, 2011 at 5:25 PM, Ralph Goers wrote:
> FWIW, I have been working heavily on Log4
Yes, Ceki created SLF4J and Logback based on his experience with 1.2 and 1.3.
The logging community is pretty small and really could use more people
involved. I've had quite a bit of experience with logging for my employer as
our needs are a bit different than what most people use a logging fra
Great news Ralph. I look forward to the new version.
Gary
On Jul 28, 2011, at 20:26, Ralph Goers wrote:
> FWIW, I have been working heavily on Log4J version 2 and would hope you'd
> help with that before going to SLF4J [1]. I have separated the API and Impl
> in a manner similar to SLF4J/Logb
Good deal Ralph! Didn't the creator of Log4j abandon the 1.2/1.3
branch to make SLF4J? Anyways, I have no idea why all the creativity
for logging went outside of Apache, but I would definitely like to see
a version 2.0.
You taking feature requests yet in JIRA? :-)
Paul
On Thu, Jul 28, 2011 at 7:
FWIW, I have been working heavily on Log4J version 2 and would hope you'd help
with that before going to SLF4J [1]. I have separated the API and Impl in a
manner similar to SLF4J/Logback but am working to correct some problems I've
encountered using each of those where I work.
Ralph
[1]
https
hahahaha :D
I asked because there's one user that proposed a [chain] evolution,
and one of suggested improvements is migrating over slf4j - I
(wrongly, maybe) suggested to keep [logging] because here at commons
we continue using it but, as said, I maybe reported a wrong fact.
Do we encourage suc
Personally I'm happy for commons-logging to die. :)
On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi
wrote:
> Hi all guys,
> I remember I raw a thread - not sure if I did it here at commons or
> somewhere else here at apache - where specified we prefer adding
> [logging] as components dependency
Hi all guys,
I remember I raw a thread - not sure if I did it here at commons or
somewhere else here at apache - where specified we prefer adding
[logging] as components dependency instead of slf4j...
Did I just get crazy or someone can point me to the right direction please? :)
Many thanks in adva
81 matches
Mail list logo
