You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Christian Grobmeier <gr...@gmail.com> on 2009/12/11 10:50:18 UTC
Fwd: Future development of Log4J?
originally sent to the wrong list, sorry for the crosspost :-)
---------- Forwarded message ----------
From: Christian Grobmeier <gr...@gmail.com>
Date: Thu, Dec 10, 2009 at 2:02 AM
Subject: Future development of Log4J?
To: Log4PHP Dev <lo...@logging.apache.org>
Hi all,
I looked at the svn of Log4J and saw that there is no activity on the
2.0 branch for 17 months. It seems that the 2.0 effort has been
stopped 3 months after the failure of 1.3. On the 1.2 trunk Curt is
still doing a great job with fixing bugs and caring about a new
release. But it seems that he is rather alone with Scott. It also
feels that Log4J is not having big step forwards, its more in a
maintenance mode. And I am wondering why, because Log4J is still one
of the most used frameworks for logging in most projects I know.
However, I also looked into the code. With my experience I took with
me with developing Log4PHP (which was quite near to the architecture
of Log4J) I spotted out the project. I feel that Log4J needs much
bigger steps now. It looks like outdated syntax which has been written
for old versions of the JDK, very complex design (lots of extensions,
deprecations and so on) and a very weird code format. I think there
can be done much more as JDKs have progressed.
Since there is less activity at all, I would like to know about your
thoughts on the future development. I saw no posts at this topic at
all. However, I strongly believe that with cleaning up Log4J lots
could be won. I don't want to to step on anybodys tooth, but I think
the project needs to refactor it's stuff, not caring about backwards
compatiblity. Clean up the old deprecations and everything which was
necessary to keep performance on old JDKs, but no longer.
I am thinking on renaming packages to better names. Not longer "or"
but maybe "renderers". Then there are much different classes stored in
the same directory, which makes everything hard to understand. Please
have a look in the log4php package structure to see what I mean. On
first glance, I don't see why Category.java is necesary any longer. In
a local version I have done these two steps and it looks so much
better so far :-)
Similar approach can help with removing classes like PropertyGetter.java.
After that kind of clean up and refactoring, it should be quite easy
to attract new developers and have new features on board.
Again, I didn't want to step on anybody tooth, but I would like to see
a new step in Log4J. Otherwise I am afraid this project is going more
and more into maintenance mode, until it reaches the end of its
lifecycle. And that would be too bad!
Of course I am willing to contribute my changes or send it to any
interested party as a zip file. But be warned, junit is not running
smoothly atm :-) I am also willing to get my hands on.
Cheers,
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Fwd: Future development of Log4J?
Posted by Antonio Petrelli <an...@gmail.com>.
2009/12/11 Ceki Gülcü <ce...@qos.ch>:
> 1) For your information, as of version 0.9.18 released a few days ago,
> logback is dual-licensed under both the LGPL *and* the EPL (Eclipse
> Public License).
Cool! Great move Ceki!
FYI, the biggest problem with LGPL is that LGPL-licensed software
cannot be redistributed with Apache products. EPL is ok.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 11, 2009, at 2:24 PM, Ceki Gülcü wrote:
> Ralph Goers wrote:
>
> > This is actually my biggest issue with Logback (and SLF4J). I've been
> > thinking recently of starting work on Log4j 2.0 simply because I do
> > not like the "community" model of Logback. This is no criticism of you
> > - it should go without saying that you are extremely talented. But
> > there have been times when you have been on vacation and nothing can
> > happen. Plus having to get your approval for everything is extremely
> > frustrating. So although there are at least 5 active participants, of
> > which I am one, we are not necessarily happy or satisfied
> > participants.
>
> Point well taken. Admittedly, I can be a bottleneck. Nevertheless, the
> ASF model where there is no official leader has issues of its own. Do
> you think you'd have less trouble getting the RFC 5424 idea pushed
> through quickly at log4j-dev@? As I said in another occasion, the
> RFC 5424 idea is good, except that it's seems like a big step and I
> need some time to digest it. Don't lose hope just yet.
In all the various projects I have committed to at Apache I have found that the ASF model works very well, especially as the number of committers grows. I can't speak to what went on at Log4j years ago, although I do understand that not breaking compatibility played some part in the issues. I can understand that since logging is such a critical component. It is somewhat ironic that one of the issues facing SLF4J today is that compatibility will be broken in moving to support Java 5+. Although I know you prefer the "benevolent dictator" model, I am quite certain Logback would be even more widely used if it was Log4j 2.0. I still get queries from engineers about "what the heck is logback and why don't we use Log4j". Even though the current Log4j code is seriously outdated, the brand name is incredibly strong.
I don't pretend to believe that if SLF4J and Logback were ASF projects that the code I wrote for RFC 5424 would have been adopted as is. More than likely I would have committed it to a branch where some collaboration could take place before merging to trunk. With SLF4J/Logback all I can really do is create a fork and hope something happens. Yes, you eventually do look at submissions but it isn't really collaborative development.
I commit to several Apache projects. What is different between the ASF and QOS.ch projects is that at the ASF the group determines what happens and how, not a single individual. I can start committing to Log4j 2.0 right now. Other people can dialogue about what I am doing and then recommend changes or make them themselves. Nothing is in the hands of a single individual. Yes, this does occasionally have drawbacks, but I believe it leads to a much stronger community.
Chris Davis has given a talk at several ApacheCons - Great Code comes from Great Community - where he mentions the benevolent dictatorship model. The slides are at http://www.viddler.com/explore/chrisjdavis/videos/25/.
>
> > Oh the issue of developing log4j 2.0, my expectation is that it would
> > be largely incompatible with log4j 1.2. I would anticipate that the
> > api would either use SLF4J or, more likely, start from the existing
> > SLF4J code and modify to take advantage of Java 5+ features. The
> > internals of log4j need a large overhaul to fix locking issue by
> > taking advantage of java.util.concurrent and many of the features
> > present in logback need to be added.
>
> Looking at the bigger picture, the log4j community would render a big
> service to the java world by aligning itself with the SLF4J API
> because logging in java is in need of consolidation. However, the
> extent of the service is diminishing by the week as more and more
> projects migrate to SLF4J. By the time this is obvious to everyone,
> the exercise will become largely pointless and tragically so.
>
I see no point in having Log4j 2.0 adhere to the SLF4J 1.x API. As has been discussed on the SLF4J list, it is time to start work on upgrading to Java 5 (or 6). In the API I would like to take advantage of both generics and annotations where appropriate.
To be honest, simply because of the way the communities work I'd prefer to do that work as part of a Log4j 2.0 Facade (or API) subproject.
Ralph
Re: Future development of Log4J?
Posted by Joern Huxhorn <jo...@gmx.de>.
On 12.12.09 05:48, Ralph Goers wrote:
>>>> Oh the issue of developing log4j 2.0, my expectation is that it would
>>>> be largely incompatible with log4j 1.2. I would anticipate that the
>>>> api would either use SLF4J or, more likely, start from the existing
>>>> SLF4J code and modify to take advantage of Java 5+ features. The
>>>> internals of log4j need a large overhaul to fix locking issue by
>>>> taking advantage of java.util.concurrent and many of the features
>>>> present in logback need to be added.
>>
>>
>> SLF4J - sorry I don't know much about it. But from its website, its
>> again a QOS project and it seems to be a wrapper around various
>> logging APIs. Besides that I never had a benefit from encapsulating a
>> logging framework (I never switched from JDK logging to Log4J or vice
>> versa while developing a project) I wonder why you are referring to
>> this. Maybe I didn't get the point, but why can't we just refactor
>> Log4J and clean it up and include this locking issue and Java5
>> features you mentioned?
>
> Separating the API from the actual implementation is very good practice
> - something I wish Sun had done a better job of with JUL. You will
> encounter this problem if you try to integrate Spring on JBoss with
> Apache Jackrabbit and various other frameworks. Some use Log4j directly.
> Some java.util.logging. Other use Apache Commons Logging and some newer
> applications use SLF4J. If you want all your logging to be managed by a
> single framework with a single configuration then you need something -
> SLF4J provides a nice bridge for all these. Plus, SLF4J has some very
> nice features that other frameworks don't have.
I agree 100%.
>> I know, logging is critical, but hey, to write an ejb container like
>> the openejb guys did is much more difficult. Question is how much
>> features does a logging framework need.
It's not so much about the features but about being able to get *all*
logging to one central point, e.g. a log file.
Due to the nature of logging calls to loggers are spread over the whole
codebase, something the aspect-OP community refers to as a
cross-cutting-concern. Because of this, a breaking change in a log
system leads to serious havoc and must therefore be a) optional and b)
as minimal as possible from the perspective of the person that decides
to "take the plunge". It must also provide a significant additional
value to that users, otherwise the effort of transition isn't worth it.
We've been discussing such a change at
http://bugzilla.slf4j.org/show_bug.cgi?id=31 for >3 years and this is
IMO the right way to do it
Adding varargs to SLF4J is, on the other hand, absolutely overdue. Doing
it the right way has the potential to deliver a much-needed death-stab
to java.util.logging, the worst framework of all.
(See
http://stackoverflow.com/questions/607863/do-you-find-java-util-logging-sufficient/958211#958211
)
>>> Looking at the bigger picture, the log4j community would render a big
>>> service to the java world by aligning itself with the SLF4J API
>>> because logging in java is in need of consolidation. However, the
>>> extent of the service is diminishing by the week as more and more
>>> projects migrate to SLF4J. By the time this is obvious to everyone,
>>> the exercise will become largely pointless and tragically so.
>>
>> Ceki, are you saying: "Log4J is dead and logback is the future. Give
>> up all development, SLF4J is stronger"?
>>
>
> SLF4J is an API, not a logging implementation. Logback is a more modern
> logging implementation and addresses many, but not all, of the issues
> Log4j still suffers from. It was time to start working on Log4j 2.0 18
> months ago but it isn't a trivial project.
I think that any work put into Log4J 2.0 involves a heavy risk of
actually wasting time, simply duplicating an effort that has already
been done in Logback.
I, personally, would *never* use it directly (i.e. without an facade)
and nobody influenced by me would do it, either.
I've switched from Log4J to commons.logging to SLF4J in the past and I'm
not to keen to repeat an effort like this (see b) above).
I refrain from log4j.NDC even though I could really, really use it very
well in my projects, simply because SLF4J does not support it.
I haven't used log4j.MDC while using commons.logging, too, for the very
same reasons: being able to switch the logging backend at will.
NDC is, for me, the biggest omission from SLF4J. Beside varargs, obviously.
Regards,
Joern.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 11, 2009, at 5:02 PM, Christian Grobmeier wrote:
> Hi,
>
> That being said, I do not use closed source frameworks because of the
> risk of vendor lock in. I use Apache software because I feel good with
> it. Logback/SLF4J is open source but driven by a company with a
> commercial interest in that software and I usually want to avoid a
> link between me and such companies if possible (except I work for
> them).
To be fair I have never heard Ceki push his company on any of the mailing lists. To be honest, I really have no idea what Ceki does to earn a living. I don't think he has ever mentioned it on the list. Once he did mention that a feature might be too large for him to do for free, but whatever it was I ended up fixing it myself.
>
>>> Oh the issue of developing log4j 2.0, my expectation is that it would
>>> be largely incompatible with log4j 1.2. I would anticipate that the
>>> api would either use SLF4J or, more likely, start from the existing
>>> SLF4J code and modify to take advantage of Java 5+ features. The
>>> internals of log4j need a large overhaul to fix locking issue by
>>> taking advantage of java.util.concurrent and many of the features
>>> present in logback need to be added.
>
>
> SLF4J - sorry I don't know much about it. But from its website, its
> again a QOS project and it seems to be a wrapper around various
> logging APIs. Besides that I never had a benefit from encapsulating a
> logging framework (I never switched from JDK logging to Log4J or vice
> versa while developing a project) I wonder why you are referring to
> this. Maybe I didn't get the point, but why can't we just refactor
> Log4J and clean it up and include this locking issue and Java5
> features you mentioned?
Separating the API from the actual implementation is very good practice - something I wish Sun had done a better job of with JUL. You will encounter this problem if you try to integrate Spring on JBoss with Apache Jackrabbit and various other frameworks. Some use Log4j directly. Some java.util.logging. Other use Apache Commons Logging and some newer applications use SLF4J. If you want all your logging to be managed by a single framework with a single configuration then you need something - SLF4J provides a nice bridge for all these. Plus, SLF4J has some very nice features that other frameworks don't have.
>
> I know, logging is critical, but hey, to write an ejb container like
> the openejb guys did is much more difficult. Question is how much
> features does a logging framework need.
>
>
>> Looking at the bigger picture, the log4j community would render a big
>> service to the java world by aligning itself with the SLF4J API
>> because logging in java is in need of consolidation. However, the
>> extent of the service is diminishing by the week as more and more
>> projects migrate to SLF4J. By the time this is obvious to everyone,
>> the exercise will become largely pointless and tragically so.
>
> Ceki, are you saying: "Log4J is dead and logback is the future. Give
> up all development, SLF4J is stronger"?
>
SLF4J is an API, not a logging implementation. Logback is a more modern logging implementation and addresses many, but not all, of the issues Log4j still suffers from. It was time to start working on Log4j 2.0 18 months ago but it isn't a trivial project.
Ralph
Re: Future development of Log4J?
Posted by Thorbjørn Ravn Andersen <no...@gmail.com>.
Den 12/12/09 02.02, Christian Grobmeier skrev:
> SLF4J - sorry I don't know much about it. But from its website, its
> again a QOS project and it seems to be a wrapper around various
> logging APIs. Besides that I never had a benefit from encapsulating a
> logging framework (I never switched from JDK logging to Log4J or vice
> versa while developing a project) I wonder why you are referring to
> this. Maybe I didn't get the point, but why can't we just refactor
> Log4J and clean it up and include this locking issue and Java5
> features you mentioned?
>
Just commenting on an old thread:
Each logging framework has advantages and disadvantages, and by using
slf4j you can postpone the decision which one to use to deployment
time. This is a good thing if you write code which is reused over
several projects, or if you have heterogeneous platforms for deployments.
It gives you an extra degree of flexibility which is nice to have.
--
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Ceki Gulcu <ce...@qos.ch>.
> Ceki, are you saying: "Log4J is dead and logback is the future. Give
> up all development, SLF4J is stronger"?
I am referring to the trend which has existed for some time now.
> Best regards,
> Christian
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Christian Grobmeier <gr...@gmail.com>.
Hi,
>> This is actually my biggest issue with Logback (and SLF4J). I've been
>> thinking recently of starting work on Log4j 2.0 simply because I do
>> not like the "community" model of Logback.
>> ...
>> Plus having to get your approval for everything is extremely
>> frustrating. So although there are at least 5 active participants, of
>> which I am one, we are not necessarily happy or satisfied
>> participants.
> Point well taken. Admittedly, I can be a bottleneck. Nevertheless, the
> ASF model where there is no official leader has issues of its own. Do
> you think you'd have less trouble getting the RFC 5424 idea pushed
> through quickly at log4j-dev@? As I said in another occasion, the
> RFC 5424 idea is good, except that it's seems like a big step and I
> need some time to digest it. Don't lose hope just yet.
I don't want to start a philosophical debate about Leadership vs
Community models. However, I don't want a leader by position, I want
to be lead by a community (and sometimes lead myself). As what I can
say in the time I was working as contributor and committer to Apache,
I was never disappointed or anything. I have learned much and like the
model as it is. I am sure that drawbacks will be removed with time,
that has already been proven.
I also saw projects made quick decisions. It's not necessary that
things stay forever. It all depends on the people working on a
project. At least, Apache Geronimo, Camel, Cocoon, OpenEJB and other
really huge projects proved that this model works - otherwise that
unbelievable great pieces of Software would never have come into
existent. I simply can't believe that such a small API like a logging
framework cannot run with this model. I cannot accept that an API like
Log4J needs a leader to become great.
That being said, I do not use closed source frameworks because of the
risk of vendor lock in. I use Apache software because I feel good with
it. Logback/SLF4J is open source but driven by a company with a
commercial interest in that software and I usually want to avoid a
link between me and such companies if possible (except I work for
them).
>> Oh the issue of developing log4j 2.0, my expectation is that it would
>> be largely incompatible with log4j 1.2. I would anticipate that the
>> api would either use SLF4J or, more likely, start from the existing
>> SLF4J code and modify to take advantage of Java 5+ features. The
>> internals of log4j need a large overhaul to fix locking issue by
>> taking advantage of java.util.concurrent and many of the features
>> present in logback need to be added.
SLF4J - sorry I don't know much about it. But from its website, its
again a QOS project and it seems to be a wrapper around various
logging APIs. Besides that I never had a benefit from encapsulating a
logging framework (I never switched from JDK logging to Log4J or vice
versa while developing a project) I wonder why you are referring to
this. Maybe I didn't get the point, but why can't we just refactor
Log4J and clean it up and include this locking issue and Java5
features you mentioned?
I know, logging is critical, but hey, to write an ejb container like
the openejb guys did is much more difficult. Question is how much
features does a logging framework need.
> Looking at the bigger picture, the log4j community would render a big
> service to the java world by aligning itself with the SLF4J API
> because logging in java is in need of consolidation. However, the
> extent of the service is diminishing by the week as more and more
> projects migrate to SLF4J. By the time this is obvious to everyone,
> the exercise will become largely pointless and tragically so.
Ceki, are you saying: "Log4J is dead and logback is the future. Give
up all development, SLF4J is stronger"?
Best regards,
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Ceki Gülcü <ce...@qos.ch>.
Ralph Goers wrote:
> This is actually my biggest issue with Logback (and SLF4J). I've been
> thinking recently of starting work on Log4j 2.0 simply because I do
> not like the "community" model of Logback. This is no criticism of you
> - it should go without saying that you are extremely talented. But
> there have been times when you have been on vacation and nothing can
> happen. Plus having to get your approval for everything is extremely
> frustrating. So although there are at least 5 active participants, of
> which I am one, we are not necessarily happy or satisfied
> participants.
Point well taken. Admittedly, I can be a bottleneck. Nevertheless, the
ASF model where there is no official leader has issues of its own. Do
you think you'd have less trouble getting the RFC 5424 idea pushed
through quickly at log4j-dev@? As I said in another occasion, the
RFC 5424 idea is good, except that it's seems like a big step and I
need some time to digest it. Don't lose hope just yet.
> Oh the issue of developing log4j 2.0, my expectation is that it would
> be largely incompatible with log4j 1.2. I would anticipate that the
> api would either use SLF4J or, more likely, start from the existing
> SLF4J code and modify to take advantage of Java 5+ features. The
> internals of log4j need a large overhaul to fix locking issue by
> taking advantage of java.util.concurrent and many of the features
> present in logback need to be added.
Looking at the bigger picture, the log4j community would render a big
service to the java world by aligning itself with the SLF4J API
because logging in java is in need of consolidation. However, the
extent of the service is diminishing by the week as more and more
projects migrate to SLF4J. By the time this is obvious to everyone,
the exercise will become largely pointless and tragically so.
--
Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 11, 2009, at 3:34 AM, Ceki Gülcü wrote:
> Thank you for your comments. Let me respond to each in turn.
>
> 1) For your information, as of version 0.9.18 released a few days ago,
> logback is dual-licensed under both the LGPL *and* the EPL (Eclipse
> Public License).
>
> 2) Logback is driven by a BDFL, that would me, following many of the
> open-source principles prevalent at the ASF. The working relationships
> within logback community, with at least 5 active participants from
> different horizons, are very good if not excellent. You are welcome to
> join and I think you should.
This is actually my biggest issue with Logback (and SLF4J). I've been thinking recently of starting work on Log4j 2.0 simply because I do not like the "community" model of Logback. This is no criticism of you - it should go without saying that you are extremely talented. But there have been times when you have been on vacation and nothing can happen. Plus having to get your approval for everything is extremely frustrating. So although there are at least 5 active participants, of which I am one, we are not necessarily happy or satisfied participants.
Oh the issue of developing log4j 2.0, my expectation is that it would be largely incompatible with log4j 1.2. I would anticipate that the api would either use SLF4J or, more likely, start from the existing SLF4J code and modify to take advantage of Java 5+ features. The internals of log4j need a large overhaul to fix locking issue by taking advantage of java.util.concurrent and many of the features present in logback need to be added.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Fwd: Future development of Log4J?
Posted by Fredrik Jonson <fr...@jonson.org>.
Ceki Gülcü wrote:
> 2) Logback is driven by a BDFL, that would me, following many of the
> open-source principles prevalent at the ASF.
I'm just a log4j user and havent contributed anything codewise to the
log4j community. Having said that, log4j being a Apache community is
_THE_ reason I want to continue using log4j in the future. There is a
huge comfort in knowing that a project is a part of Apache.
Apache projects has a certain level of quality assurance, and you know
the legal aspects are handled very carefully and correctly. Also the
community tends to survive and evolve over time in a better way than
projects outside of the Apache sphere. Also the absence of a BDFL and
any risk of overwhelming control from a single corporate organization
is of course a good thing.
While I'm at it, thanks guys! And thank you Ceki for starting the log4j
project. Log4j is - still - a great solution to a important issue in
the Java world. Thanks!
--
Fredrik Jonson
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Fwd: Future development of Log4J?
Posted by Ceki Gülcü <ce...@qos.ch>.
Thank you for your comments. Let me respond to each in turn.
1) For your information, as of version 0.9.18 released a few days ago,
logback is dual-licensed under both the LGPL *and* the EPL (Eclipse
Public License).
2) Logback is driven by a BDFL, that would me, following many of the
open-source principles prevalent at the ASF. The working relationships
within logback community, with at least 5 active participants from
different horizons, are very good if not excellent. You are welcome to
join and I think you should.
3) Indeed, many ASF projects are using log4j although a significant
percentage uses SLF4J with log4j as the underlying framework/back-end.
Until recently, those projects could *not* have used logback as the
underlying framework but that has changed. In light of the recent
licensing changes, I would expect many ASF projects to migrate to
logback, as it is objectively a better log4j.
4) The argument of complexity is quite interesting. I can tell you
that as time passes, the tendency is to have more complex code. For
example, users are calling for a more complex API (but also more
flexible) within logback internals. As you know, the client API, i.e
SLF4J, is already cast in stone and is very unlikely to change.
Anyway, I would be interested to learn about your suggested changes
or simplifications within the context of the logback project.
Cheers,
Christian Grobmeier wrote:
> Hi Ceki,
>
> thanks for pointing me to logback. But there are several reasons I
> would like to keep Log4J alive.
>
> 1) logback is distributed as LGPL, not Apache License. Both are
> compatible, but I prefer ASL.
> 2) logback is driven by a company and not an ASF project, which I
> prefer for several reasons
> 3) so much users are still using Log4J, including lots of Apache projects
> 4) old log4j and logback api feels a bit complex to me. I think both
> could be more simple
>
> That being said, logback is not an option for me at the moment nor was
> it necessary to use any of the new features it provides (speaking only
> of my own projects of course). This is why I would like to see a
> continuation on the log4j work.
>
> Best regards,
> Christian
>
>
>
> On Fri, Dec 11, 2009 at 11:02 AM, Ceki Gülcü <ce...@qos.ch> wrote:
>> Hi Christian,
>>
>> Have a look at logback. It is the continuation of the log4j 1.3
>> effort, with 4 years of additional work.
>>
>> --
>> Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Fwd: Future development of Log4J?
Posted by Christian Grobmeier <gr...@gmail.com>.
Hi Ceki,
thanks for pointing me to logback. But there are several reasons I
would like to keep Log4J alive.
1) logback is distributed as LGPL, not Apache License. Both are
compatible, but I prefer ASL.
2) logback is driven by a company and not an ASF project, which I
prefer for several reasons
3) so much users are still using Log4J, including lots of Apache projects
4) old log4j and logback api feels a bit complex to me. I think both
could be more simple
That being said, logback is not an option for me at the moment nor was
it necessary to use any of the new features it provides (speaking only
of my own projects of course). This is why I would like to see a
continuation on the log4j work.
Best regards,
Christian
On Fri, Dec 11, 2009 at 11:02 AM, Ceki Gülcü <ce...@qos.ch> wrote:
> Hi Christian,
>
> Have a look at logback. It is the continuation of the log4j 1.3
> effort, with 4 years of additional work.
>
> --
> Ceki
>
> Christian Grobmeier wrote:
>>
>> originally sent to the wrong list, sorry for the crosspost :-)
>>
>>
>> ---------- Forwarded message ----------
>> From: Christian Grobmeier <gr...@gmail.com>
>> Date: Thu, Dec 10, 2009 at 2:02 AM
>> Subject: Future development of Log4J?
>> To: Log4PHP Dev <lo...@logging.apache.org>
>>
>>
>> Hi all,
>>
>> I looked at the svn of Log4J and saw that there is no activity on the
>> 2.0 branch for 17 months. It seems that the 2.0 effort has been
>> stopped 3 months after the failure of 1.3. On the 1.2 trunk Curt is
>> still doing a great job with fixing bugs and caring about a new
>> release. But it seems that he is rather alone with Scott. It also
>> feels that Log4J is not having big step forwards, its more in a
>> maintenance mode. And I am wondering why, because Log4J is still one
>> of the most used frameworks for logging in most projects I know.
>>
>> However, I also looked into the code. With my experience I took with
>> me with developing Log4PHP (which was quite near to the architecture
>> of Log4J) I spotted out the project. I feel that Log4J needs much
>> bigger steps now. It looks like outdated syntax which has been written
>> for old versions of the JDK, very complex design (lots of extensions,
>> deprecations and so on) and a very weird code format. I think there
>> can be done much more as JDKs have progressed.
>>
>> Since there is less activity at all, I would like to know about your
>> thoughts on the future development. I saw no posts at this topic at
>> all. However, I strongly believe that with cleaning up Log4J lots
>> could be won. I don't want to to step on anybodys tooth, but I think
>> the project needs to refactor it's stuff, not caring about backwards
>> compatiblity. Clean up the old deprecations and everything which was
>> necessary to keep performance on old JDKs, but no longer.
>>
>> I am thinking on renaming packages to better names. Not longer "or"
>> but maybe "renderers". Then there are much different classes stored in
>> the same directory, which makes everything hard to understand. Please
>> have a look in the log4php package structure to see what I mean. On
>> first glance, I don't see why Category.java is necesary any longer. In
>> a local version I have done these two steps and it looks so much
>> better so far :-)
>> Similar approach can help with removing classes like PropertyGetter.java.
>>
>> After that kind of clean up and refactoring, it should be quite easy
>> to attract new developers and have new features on board.
>>
>> Again, I didn't want to step on anybody tooth, but I would like to see
>> a new step in Log4J. Otherwise I am afraid this project is going more
>> and more into maintenance mode, until it reaches the end of its
>> lifecycle. And that would be too bad!
>>
>> Of course I am willing to contribute my changes or send it to any
>> interested party as a zip file. But be warned, junit is not running
>> smoothly atm :-) I am also willing to get my hands on.
>>
>> Cheers,
>> Christian
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Fwd: Future development of Log4J?
Posted by Ceki Gülcü <ce...@qos.ch>.
Hi Christian,
Have a look at logback. It is the continuation of the log4j 1.3
effort, with 4 years of additional work.
--
Ceki
Christian Grobmeier wrote:
> originally sent to the wrong list, sorry for the crosspost :-)
>
>
> ---------- Forwarded message ----------
> From: Christian Grobmeier <gr...@gmail.com>
> Date: Thu, Dec 10, 2009 at 2:02 AM
> Subject: Future development of Log4J?
> To: Log4PHP Dev <lo...@logging.apache.org>
>
>
> Hi all,
>
> I looked at the svn of Log4J and saw that there is no activity on the
> 2.0 branch for 17 months. It seems that the 2.0 effort has been
> stopped 3 months after the failure of 1.3. On the 1.2 trunk Curt is
> still doing a great job with fixing bugs and caring about a new
> release. But it seems that he is rather alone with Scott. It also
> feels that Log4J is not having big step forwards, its more in a
> maintenance mode. And I am wondering why, because Log4J is still one
> of the most used frameworks for logging in most projects I know.
>
> However, I also looked into the code. With my experience I took with
> me with developing Log4PHP (which was quite near to the architecture
> of Log4J) I spotted out the project. I feel that Log4J needs much
> bigger steps now. It looks like outdated syntax which has been written
> for old versions of the JDK, very complex design (lots of extensions,
> deprecations and so on) and a very weird code format. I think there
> can be done much more as JDKs have progressed.
>
> Since there is less activity at all, I would like to know about your
> thoughts on the future development. I saw no posts at this topic at
> all. However, I strongly believe that with cleaning up Log4J lots
> could be won. I don't want to to step on anybodys tooth, but I think
> the project needs to refactor it's stuff, not caring about backwards
> compatiblity. Clean up the old deprecations and everything which was
> necessary to keep performance on old JDKs, but no longer.
>
> I am thinking on renaming packages to better names. Not longer "or"
> but maybe "renderers". Then there are much different classes stored in
> the same directory, which makes everything hard to understand. Please
> have a look in the log4php package structure to see what I mean. On
> first glance, I don't see why Category.java is necesary any longer. In
> a local version I have done these two steps and it looks so much
> better so far :-)
> Similar approach can help with removing classes like PropertyGetter.java.
>
> After that kind of clean up and refactoring, it should be quite easy
> to attract new developers and have new features on board.
>
> Again, I didn't want to step on anybody tooth, but I would like to see
> a new step in Log4J. Otherwise I am afraid this project is going more
> and more into maintenance mode, until it reaches the end of its
> lifecycle. And that would be too bad!
>
> Of course I am willing to contribute my changes or send it to any
> interested party as a zip file. But be warned, junit is not running
> smoothly atm :-) I am also willing to get my hands on.
>
> Cheers,
> Christian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Scott Deboy <sc...@gmail.com>.
I'd suspect in those cases where you were trying to get a log viewer to
process the events, you wouldn't bother passing custom objects via TCP
unless you wanted to develop a custom receiver to parse it...In Chainsaw's
case, I'd suggest using (VFS)LogFilePatternReceiver to process the events
(just include an additional appender).
Scott
On Mon, Feb 22, 2010 at 12:22 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>
> On Feb 21, 2010, at 8:22 PM, Curt Arnold wrote:
>
> >
> > On Feb 20, 2010, at 11:16 AM, Ralph Goers wrote:
> >>
> >> I'd prefer a Message instead of an Object. The primary difference is
> that the Message is an interface that looks like:
> >>
> >> /**
> >> * An interface for various Message implementations that can be logged.
> >> */
> >> public interface Message extends Serializable {
> >> /**
> >> * Returns the Message formatted as a String.
> >> * @return The message String.
> >> */
> >> String getFormattedMessage();
> >>
> >> /**
> >> * Returns the format portion of the Message
> >> * @return
> >> */
> >> String getMessageFormat();
> >>
> >> /**
> >> * Returns parameter values, if any.
> >> * @return An array of parameter values or null.
> >> */
> >> Object[] getParameters();
> >> }
> >>
> >> For SLF4J I implemented a ParameterizedMessage (message and parameters),
> a SimpleMessage (message string only), and StructuredDataMessage (to support
> RFC 5424), but all kinds of Message objects could be created. This makes it
> easy for appenders and layouts because they just need to call
> getFormattedMessage() to include that in the layout, or they can get to the
> "message" via getMessageFormat() or the "parameters" via getParameters().
> >>
> >> Ralph
> >>
> >
> > I'd expect that parameterized log requests would end up packing the
> format string and parameters into an object for evaluation in the extraction
> phase. There are two different formatters in the Java library in addition
> to the SLF4J formatter, so if you were interested in making sense of the
> format string, you'd need to do an instanceof to determine which formatter
> was being used. I'm thinking it is best just to rely on Object.toString()
> to get the formatted string, If something in the stack wants to do
> something funky with the message format string or parameters, they can use
> instanceof to cast to a specific class.
> >
> > We'd likely end up with an ParameterizedMessage interface with the
> getParameters() method and then concrete classes for the
> SimpleFormatParameterizedMessage, MessageFormatParameterizedMessage,
> FormatterParameterizedMessage, et al. I'd definitely like to stay using
> Object for the message parameter in the core until there is a clear benefit
> to being more restrictive. Should make it easier to support log4j's lack
> of restriction on the message parameter if we don't have to repackage it as
> a single parameter parameterized message,
>
> Well, I've finally begun doing some coding this weekend although I haven't
> gotten awfully far. I am definitely going to be using the Message interface.
> There were some lengthy discussions on the Logback list about this topic and
> the problems using an Object introduces for applications like Lillith or
> Chainsaw where the Object has to be passed to a remote system. Often
> serialization fails miserably and toString often yields unsatisfying
> results. It also requires the remote application to have the Classes in the
> class path for the objects being sent to it to be able to deserialize the
> events, which can be a pain for a general purpose logging reporting
> application.
>
> Ralph
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
Re: Future development of Log4J?
Posted by Jess Holle <je...@ptc.com>.
On 2/22/2010 2:14 AM, Ralph Goers wrote:
>
> On Feb 21, 2010, at 5:22 PM, Jess Holle wrote:
>
>> On 2/20/2010 11:16 AM, Ralph Goers wrote:
>>>> One thing I'd like to make sure is not lost is an easy way to pass an Object rather than a String.
>>>>
>>> I'd prefer a Message instead of an Object. The primary difference is that the Message is an interface that looks like:
>>>
>> That initially seems reasonable (though I'm not sure about
>> getMessageFormat() -- if your formatted message is simple tab
>> delimited would this then be a string containing 'n' tabs?)
>>
>> Looking further, though, I'm less certain. For instance, I pass
>> DynamicMBeans as my message Object in cases. getParameters() could
>> be expensive here. Instead, my custom appenders are configured with
>> the list of attributes to obtain in the case of DynamicMBean messages
>> -- so only those getters are called. getParameters() denies the
>> possibility of such "just enough" data access.
> Message is an interface with only those three methods being required.
> If you wish to create a Message class that adds support for additional
> features you would be free to do so. In that case your Appender would
> just do an instanceof to take advantage of the custom features.
> However, "regular" appenders would still be able to handle your
> objects because you would implement those methods appropriately.
Okay, that makes sense -- except for lingering questions about
getMessageFormat() as per Curt's point.
--
Jess Holle
Re: Future development of Log4J?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Feb 21, 2010, at 5:22 PM, Jess Holle wrote:
> On 2/20/2010 11:16 AM, Ralph Goers wrote:
>>> One thing I'd like to make sure is not lost is an easy way to pass an Object rather than a String.
>>>
>> I'd prefer a Message instead of an Object. The primary difference is that the Message is an interface that looks like:
>>
> That initially seems reasonable (though I'm not sure about getMessageFormat() -- if your formatted message is simple tab delimited would this then be a string containing 'n' tabs?)
>
> Looking further, though, I'm less certain. For instance, I pass DynamicMBeans as my message Object in cases. getParameters() could be expensive here. Instead, my custom appenders are configured with the list of attributes to obtain in the case of DynamicMBean messages -- so only those getters are called. getParameters() denies the possibility of such "just enough" data access.
Message is an interface with only those three methods being required. If you wish to create a Message class that adds support for additional features you would be free to do so. In that case your Appender would just do an instanceof to take advantage of the custom features. However, "regular" appenders would still be able to handle your objects because you would implement those methods appropriately.
Ralph
Re: Future development of Log4J?
Posted by Jess Holle <je...@ptc.com>.
On 2/20/2010 11:16 AM, Ralph Goers wrote:
>> One thing I'd like to make sure is not lost is an easy way to pass an Object rather than a String.
>>
> I'd prefer a Message instead of an Object. The primary difference is that the Message is an interface that looks like:
>
That initially seems reasonable (though I'm not sure about
getMessageFormat() -- if your formatted message is simple tab delimited
would this then be a string containing 'n' tabs?)
Looking further, though, I'm less certain. For instance, I pass
DynamicMBeans as my message Object in cases. getParameters() could be
expensive here. Instead, my custom appenders are configured with the
list of attributes to obtain in the case of DynamicMBean messages -- so
only those getters are called. getParameters() denies the possibility
of such "just enough" data access.
> /**
> * An interface for various Message implementations that can be logged.
> */
> public interface Message extends Serializable {
> /**
> * Returns the Message formatted as a String.
> * @return The message String.
> */
> String getFormattedMessage();
>
> /**
> * Returns the format portion of the Message
> * @return
> */
> String getMessageFormat();
>
> /**
> * Returns parameter values, if any.
> * @return An array of parameter values or null.
> */
> Object[] getParameters();
> }
>
> For SLF4J I implemented a ParameterizedMessage (message and parameters), a SimpleMessage (message string only), and StructuredDataMessage (to support RFC 5424), but all kinds of Message objects could be created. This makes it easy for appenders and layouts because they just need to call getFormattedMessage() to include that in the layout, or they can get to the "message" via getMessageFormat() or the "parameters" via getParameters().
Re: Future development of Log4J?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Feb 22, 2010, at 5:45 AM, Curt Arnold wrote:
>
>
> Do you have critiques of the earlier work in http://svn.apache.org/repos/asf/logging/sandbox/experimental/pattern-layout? I should move that over to BRANCH_2_0_EXPERIMENTAL.
>
No, I haven't looked at it. But I will.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Feb 22, 2010, at 6:41 AM, Curt Arnold wrote:
>
> On Feb 22, 2010, at 7:45 AM, Curt Arnold wrote:
>
>>
>> Please start a directory off http://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL for this work. We want to avoid having a whole bunch of code hit the SVN repo in a "finished" state. Please describe your approach, goals, scope to the list.
>
> Could you create a multi-project pom.xml in BRANCH_2_0_EXPERIMENTAL and then put your proposal as a sub-project under it and could you give your proposal a code name. I'll try to bring over my earlier work and fit it into the same structure. At this point, I think we should gather requirements and gather code experiments and then later sort out what parts we use to assemble the first log4j 2.0 base.
>
Yes, that is a reasonable way to go. It would also allow me to commit code before it actually works so you can have a better idea what I am talking about. But I still have a bit of a way to go before I commit anything.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Curt Arnold <ca...@apache.org>.
On Feb 22, 2010, at 7:45 AM, Curt Arnold wrote:
>
> Please start a directory off http://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL for this work. We want to avoid having a whole bunch of code hit the SVN repo in a "finished" state. Please describe your approach, goals, scope to the list.
Could you create a multi-project pom.xml in BRANCH_2_0_EXPERIMENTAL and then put your proposal as a sub-project under it and could you give your proposal a code name. I'll try to bring over my earlier work and fit it into the same structure. At this point, I think we should gather requirements and gather code experiments and then later sort out what parts we use to assemble the first log4j 2.0 base.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Curt Arnold <ca...@apache.org>.
On Feb 22, 2010, at 2:22 AM, Ralph Goers wrote:
> Well, I've finally begun doing some coding this weekend although I haven't gotten awfully far. I am definitely going to be using the Message interface. There were some lengthy discussions on the Logback list about this topic and the problems using an Object introduces for applications like Lillith or Chainsaw where the Object has to be passed to a remote system. Often serialization fails miserably and toString often yields unsatisfying results. It also requires the remote application to have the Classes in the class path for the objects being sent to it to be able to deserialize the events, which can be a pain for a general purpose logging reporting application.
>
> Ralph
>
Please log the issues that you see with using Object as the message parameter as JIRA issues with links to the logback discussion threads. It would document the motivation behind a design decision, or allow satisfying those requirements through a different means.
On serialization, it seems like you are anticipating preventing log4j's capability to send arbitrary classes over the wire. While it can be problematic, it can also be used properly.
Please start a directory off http://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL for this work. We want to avoid having a whole bunch of code hit the SVN repo in a "finished" state. Please describe your approach, goals, scope to the list.
Do you have critiques of the earlier work in http://svn.apache.org/repos/asf/logging/sandbox/experimental/pattern-layout? I should move that over to BRANCH_2_0_EXPERIMENTAL.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Feb 21, 2010, at 8:22 PM, Curt Arnold wrote:
>
> On Feb 20, 2010, at 11:16 AM, Ralph Goers wrote:
>>
>> I'd prefer a Message instead of an Object. The primary difference is that the Message is an interface that looks like:
>>
>> /**
>> * An interface for various Message implementations that can be logged.
>> */
>> public interface Message extends Serializable {
>> /**
>> * Returns the Message formatted as a String.
>> * @return The message String.
>> */
>> String getFormattedMessage();
>>
>> /**
>> * Returns the format portion of the Message
>> * @return
>> */
>> String getMessageFormat();
>>
>> /**
>> * Returns parameter values, if any.
>> * @return An array of parameter values or null.
>> */
>> Object[] getParameters();
>> }
>>
>> For SLF4J I implemented a ParameterizedMessage (message and parameters), a SimpleMessage (message string only), and StructuredDataMessage (to support RFC 5424), but all kinds of Message objects could be created. This makes it easy for appenders and layouts because they just need to call getFormattedMessage() to include that in the layout, or they can get to the "message" via getMessageFormat() or the "parameters" via getParameters().
>>
>> Ralph
>>
>
> I'd expect that parameterized log requests would end up packing the format string and parameters into an object for evaluation in the extraction phase. There are two different formatters in the Java library in addition to the SLF4J formatter, so if you were interested in making sense of the format string, you'd need to do an instanceof to determine which formatter was being used. I'm thinking it is best just to rely on Object.toString() to get the formatted string, If something in the stack wants to do something funky with the message format string or parameters, they can use instanceof to cast to a specific class.
>
> We'd likely end up with an ParameterizedMessage interface with the getParameters() method and then concrete classes for the SimpleFormatParameterizedMessage, MessageFormatParameterizedMessage, FormatterParameterizedMessage, et al. I'd definitely like to stay using Object for the message parameter in the core until there is a clear benefit to being more restrictive. Should make it easier to support log4j's lack of restriction on the message parameter if we don't have to repackage it as a single parameter parameterized message,
Well, I've finally begun doing some coding this weekend although I haven't gotten awfully far. I am definitely going to be using the Message interface. There were some lengthy discussions on the Logback list about this topic and the problems using an Object introduces for applications like Lillith or Chainsaw where the Object has to be passed to a remote system. Often serialization fails miserably and toString often yields unsatisfying results. It also requires the remote application to have the Classes in the class path for the objects being sent to it to be able to deserialize the events, which can be a pain for a general purpose logging reporting application.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Curt Arnold <ca...@apache.org>.
On Feb 20, 2010, at 11:16 AM, Ralph Goers wrote:
>
> I'd prefer a Message instead of an Object. The primary difference is that the Message is an interface that looks like:
>
> /**
> * An interface for various Message implementations that can be logged.
> */
> public interface Message extends Serializable {
> /**
> * Returns the Message formatted as a String.
> * @return The message String.
> */
> String getFormattedMessage();
>
> /**
> * Returns the format portion of the Message
> * @return
> */
> String getMessageFormat();
>
> /**
> * Returns parameter values, if any.
> * @return An array of parameter values or null.
> */
> Object[] getParameters();
> }
>
> For SLF4J I implemented a ParameterizedMessage (message and parameters), a SimpleMessage (message string only), and StructuredDataMessage (to support RFC 5424), but all kinds of Message objects could be created. This makes it easy for appenders and layouts because they just need to call getFormattedMessage() to include that in the layout, or they can get to the "message" via getMessageFormat() or the "parameters" via getParameters().
>
> Ralph
>
I'd expect that parameterized log requests would end up packing the format string and parameters into an object for evaluation in the extraction phase. There are two different formatters in the Java library in addition to the SLF4J formatter, so if you were interested in making sense of the format string, you'd need to do an instanceof to determine which formatter was being used. I'm thinking it is best just to rely on Object.toString() to get the formatted string, If something in the stack wants to do something funky with the message format string or parameters, they can use instanceof to cast to a specific class.
We'd likely end up with an ParameterizedMessage interface with the getParameters() method and then concrete classes for the SimpleFormatParameterizedMessage, MessageFormatParameterizedMessage, FormatterParameterizedMessage, et al. I'd definitely like to stay using Object for the message parameter in the core until there is a clear benefit to being more restrictive. Should make it easier to support log4j's lack of restriction on the message parameter if we don't have to repackage it as a single parameter parameterized message,
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Feb 20, 2010, at 8:27 AM, Jess Holle wrote:
> On 2/19/2010 10:22 PM, Curt Arnold wrote:
>> On Feb 19, 2010, at 5:42 PM, Christian Grobmeier wrote:
>>
>>> However - we (all who are interested in continuing log4j) need to
>>> discuss other options. Using SLF4J as native interface or not might be
>>> the next discussion. Looking at the current code we currently have is
>>> the next one.
>>>
>> Before jumping into implementation issues, I think it would be best to try to collect as many potential requirements, design principles, etc, so we know what things are important to us and to our potential users before starting to make design decisions. There are several usable logging frameworks out there, it would be good to know what issues are bothersome, limiting, irritating, desirable, etc. We may need to sacrifice one feature for another, but it would be best to know that we are making trade-offs.
>>
>> I requested a log4j 2.0 JIRA (https://issues.apache.org/jira/browse/LOG4J2) several years ago to serve as a place to collect that type of info. I've entered much of the stuff there, but none of them should be taken as mandates or directives. They are ideas. I thought they were good at the time. I would love to see other people throw in their ideas and pains, help refine others, etc. At some point, we can start to narrow down which are required, desirable, marginal or impractical.
>>
>> Probably would be good to invite the other ASF projects that have a logging dependency to post their issues, concerns or wishes.
>>
>> Supporting SLF4J as an interface is already logged as a design issue (http://issues.apache.org/jira/browse/LOG4J2-27). However, I think it is strongly desirable to make much of log4j 2.0's back-end classes independent of the logging API which was the gist of LOG4J2-5.
>>
>> In my mind, what defines log4j 2.0 are LOG4J2-3 (fine grained locking) and LOG4J2-7 (designed for JDK 5+) with LOG4J2-4 being likely the next most significant.
>>
>> Experimenting with some of the core issues to clarify ideas is probably valuable. The stuff I did in the sandbox was to explore LOG4J2-13 (distinct extract/render phases) and LOG4J2-5 (backend independence from API).
>>
>> Another area worthy of exploration is LOG4J2-9, basically designing log4j 2.0 to be configurable from multiple configuration frameworks.
>>
> Those sound like good targets.
>
> One thing I'd like to make sure is not lost is an easy way to pass an Object rather than a String.
I'd prefer a Message instead of an Object. The primary difference is that the Message is an interface that looks like:
/**
* An interface for various Message implementations that can be logged.
*/
public interface Message extends Serializable {
/**
* Returns the Message formatted as a String.
* @return The message String.
*/
String getFormattedMessage();
/**
* Returns the format portion of the Message
* @return
*/
String getMessageFormat();
/**
* Returns parameter values, if any.
* @return An array of parameter values or null.
*/
Object[] getParameters();
}
For SLF4J I implemented a ParameterizedMessage (message and parameters), a SimpleMessage (message string only), and StructuredDataMessage (to support RFC 5424), but all kinds of Message objects could be created. This makes it easy for appenders and layouts because they just need to call getFormattedMessage() to include that in the layout, or they can get to the "message" via getMessageFormat() or the "parameters" via getParameters().
Ralph
>
> This allows custom appenders and layouts to recognize particular Object types and do things like route fields, map values, or the like to separate database or CSV/TSV columns -- while letting the Object provide a toString() or using a custom renderer for other cases.
>
> If only a String is passed or using clumsy syntax is required to pass an Object, then such richly structured output is defeated.
>
> --
> Jess Holle
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Jess Holle <je...@ptc.com>.
On 2/19/2010 10:22 PM, Curt Arnold wrote:
> On Feb 19, 2010, at 5:42 PM, Christian Grobmeier wrote:
>
>> However - we (all who are interested in continuing log4j) need to
>> discuss other options. Using SLF4J as native interface or not might be
>> the next discussion. Looking at the current code we currently have is
>> the next one.
>>
> Before jumping into implementation issues, I think it would be best to try to collect as many potential requirements, design principles, etc, so we know what things are important to us and to our potential users before starting to make design decisions. There are several usable logging frameworks out there, it would be good to know what issues are bothersome, limiting, irritating, desirable, etc. We may need to sacrifice one feature for another, but it would be best to know that we are making trade-offs.
>
> I requested a log4j 2.0 JIRA (https://issues.apache.org/jira/browse/LOG4J2) several years ago to serve as a place to collect that type of info. I've entered much of the stuff there, but none of them should be taken as mandates or directives. They are ideas. I thought they were good at the time. I would love to see other people throw in their ideas and pains, help refine others, etc. At some point, we can start to narrow down which are required, desirable, marginal or impractical.
>
> Probably would be good to invite the other ASF projects that have a logging dependency to post their issues, concerns or wishes.
>
> Supporting SLF4J as an interface is already logged as a design issue (http://issues.apache.org/jira/browse/LOG4J2-27). However, I think it is strongly desirable to make much of log4j 2.0's back-end classes independent of the logging API which was the gist of LOG4J2-5.
>
> In my mind, what defines log4j 2.0 are LOG4J2-3 (fine grained locking) and LOG4J2-7 (designed for JDK 5+) with LOG4J2-4 being likely the next most significant.
>
> Experimenting with some of the core issues to clarify ideas is probably valuable. The stuff I did in the sandbox was to explore LOG4J2-13 (distinct extract/render phases) and LOG4J2-5 (backend independence from API).
>
> Another area worthy of exploration is LOG4J2-9, basically designing log4j 2.0 to be configurable from multiple configuration frameworks.
>
Those sound like good targets.
One thing I'd like to make sure is not lost is an easy way to pass an
Object rather than a String.
This allows custom appenders and layouts to recognize particular Object
types and do things like route fields, map values, or the like to
separate database or CSV/TSV columns -- while letting the Object provide
a toString() or using a custom renderer for other cases.
If only a String is passed or using clumsy syntax is required to pass an
Object, then such richly structured output is defeated.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Feb 19, 2010, at 8:22 PM, Curt Arnold wrote:
>
> On Feb 19, 2010, at 5:42 PM, Christian Grobmeier wrote:
>>
>> However - we (all who are interested in continuing log4j) need to
>> discuss other options. Using SLF4J as native interface or not might be
>> the next discussion. Looking at the current code we currently have is
>> the next one.
>>
>
> Before jumping into implementation issues, I think it would be best to try to collect as many potential requirements, design principles, etc, so we know what things are important to us and to our potential users before starting to make design decisions. There are several usable logging frameworks out there, it would be good to know what issues are bothersome, limiting, irritating, desirable, etc. We may need to sacrifice one feature for another, but it would be best to know that we are making trade-offs.
>
> I requested a log4j 2.0 JIRA (https://issues.apache.org/jira/browse/LOG4J2) several years ago to serve as a place to collect that type of info. I've entered much of the stuff there, but none of them should be taken as mandates or directives. They are ideas. I thought they were good at the time. I would love to see other people throw in their ideas and pains, help refine others, etc. At some point, we can start to narrow down which are required, desirable, marginal or impractical.
>
> Probably would be good to invite the other ASF projects that have a logging dependency to post their issues, concerns or wishes.
>
> Supporting SLF4J as an interface is already logged as a design issue (http://issues.apache.org/jira/browse/LOG4J2-27). However, I think it is strongly desirable to make much of log4j 2.0's back-end classes independent of the logging API which was the gist of LOG4J2-5.
I agree with this. I also think the interface should be in a separate API jar. If we want to make the implementation pluggable that is fine by me as well.
>
> In my mind, what defines log4j 2.0 are LOG4J2-3 (fine grained locking) and LOG4J2-7 (designed for JDK 5+) with LOG4J2-4 being likely the next most significant.
Actually, I'd like to target Java 6 since it has better support for annotations. Of course, the annotation support could probably be provided separately.
>
> Experimenting with some of the core issues to clarify ideas is probably valuable. The stuff I did in the sandbox was to explore LOG4J2-13 (distinct extract/render phases) and LOG4J2-5 (backend independence from API).
>
> Another area worthy of exploration is LOG4J2-9, basically designing log4j 2.0 to be configurable from multiple configuration frameworks.
>
Yes, using an SPI and allowing the configuration to be pluggable would be good but can get very tricky, especially since Log4j needs to support dynamic reconfiguration.
I've opened a few more Jira issues regarding support for annotations and for supporting Message objects. I've implemented this for Logback and would like to see this be a fundamental part of Log4j 2.0.
BTW - logging.apache.org and http://logging.apache.org/log4j/2.0/index.html don't seem to have a link to Jira.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Curt Arnold <ca...@apache.org>.
On Feb 19, 2010, at 5:42 PM, Christian Grobmeier wrote:
>
> However - we (all who are interested in continuing log4j) need to
> discuss other options. Using SLF4J as native interface or not might be
> the next discussion. Looking at the current code we currently have is
> the next one.
>
Before jumping into implementation issues, I think it would be best to try to collect as many potential requirements, design principles, etc, so we know what things are important to us and to our potential users before starting to make design decisions. There are several usable logging frameworks out there, it would be good to know what issues are bothersome, limiting, irritating, desirable, etc. We may need to sacrifice one feature for another, but it would be best to know that we are making trade-offs.
I requested a log4j 2.0 JIRA (https://issues.apache.org/jira/browse/LOG4J2) several years ago to serve as a place to collect that type of info. I've entered much of the stuff there, but none of them should be taken as mandates or directives. They are ideas. I thought they were good at the time. I would love to see other people throw in their ideas and pains, help refine others, etc. At some point, we can start to narrow down which are required, desirable, marginal or impractical.
Probably would be good to invite the other ASF projects that have a logging dependency to post their issues, concerns or wishes.
Supporting SLF4J as an interface is already logged as a design issue (http://issues.apache.org/jira/browse/LOG4J2-27). However, I think it is strongly desirable to make much of log4j 2.0's back-end classes independent of the logging API which was the gist of LOG4J2-5.
In my mind, what defines log4j 2.0 are LOG4J2-3 (fine grained locking) and LOG4J2-7 (designed for JDK 5+) with LOG4J2-4 being likely the next most significant.
Experimenting with some of the core issues to clarify ideas is probably valuable. The stuff I did in the sandbox was to explore LOG4J2-13 (distinct extract/render phases) and LOG4J2-5 (backend independence from API).
Another area worthy of exploration is LOG4J2-9, basically designing log4j 2.0 to be configurable from multiple configuration frameworks.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Ceki Gülcü <ce...@qos.ch>.
On 20/02/2010 12:42 AM, Christian Grobmeier wrote:
> Thanks Ceki for your long and detailled answer. You are right, i
> missed a word out in my mail - I meant "if we would take logback as
> base for new development", as you suggested in a previous mail (so i
> understood it).
I had not openly excluded the possibility but have not suggested it
either.
> However. if you are not willing to contribute logback with a software
> grant, then of course the "use logback" discussion can stop now. I
> understood that you were thinking about donating but have changed your
> mind. To be honest, even when I think that logback is very well and it
> would do fine as Log4J 2, there might be other discussions which could
> lead to frustrations on several sides. I think on discussions like
> having author tags and such.
Author tags is a way of recognizing contributors. Recognition is a
very important aspect of oss.
> Having in mind that there is some heat in all the discussion on this
> list, I also think this isn't the right time for contributing logback.
Indeed.
> However - we (all who are interested in continuing log4j) need to
> discuss other options. Using SLF4J as native interface or not might be
> the next discussion. Looking at the current code we currently have is
> the next one.
Sounds good.
> Cheers
> Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Christian Grobmeier <gr...@gmail.com>.
Thanks Ceki for your long and detailled answer. You are right, i
missed a word out in my mail - I meant "if we would take logback as
base for new development", as you suggested in a previous mail (so i
understood it).
However. if you are not willing to contribute logback with a software
grant, then of course the "use logback" discussion can stop now. I
understood that you were thinking about donating but have changed your
mind. To be honest, even when I think that logback is very well and it
would do fine as Log4J 2, there might be other discussions which could
lead to frustrations on several sides. I think on discussions like
having author tags and such.
Having in mind that there is some heat in all the discussion on this
list, I also think this isn't the right time for contributing logback.
However - we (all who are interested in continuing log4j) need to
discuss other options. Using SLF4J as native interface or not might be
the next discussion. Looking at the current code we currently have is
the next one.
Cheers
Christian
On Fri, Feb 19, 2010 at 7:59 PM, Ceki Gülcü <ce...@qos.ch> wrote:
> Christian,
>
> When you say "we would logback", it's not exactly clear what you mean.
>
> Anyway, to answer your question, Logback is dual licensed under LGPL
> and EPL per the licensee's choosing. Both licenses are reciprocal,
> but the LGPL has a legal clause requiring the client code to authorize
> debugging which the ASF does not deem acceptable. LGPL, in ASF
> terminology, is an "excluded license". Since logback is EPLed, it can
> be used by Apache projects in binary form but with respect to derivative
> works, for example if you copy a logback source file and incorporate
> it into log4j, the said work would need to be distributed under the
> EPL.
>
> Even if logback was licensed under the Apache Software License, you
> still can't change the copyright attributions because even the Apache
> Software License requires that existing copyright notices be preserved.
>
> For the definition of "reciprocal" and "excluded" as well as other 3rd
> party licenses, see
>
> http://www.apache.org/legal/3party.html
>
> In short, copying source code from an open-source project licensed
> under any "common" open-source license (GPL, LGPL, ASL, EPL, MPL,
> BSD..) *and* removing existing copyright notices is not allowed.
> I don't see how one could comfortably import logback into
> the ASF without a software grant by the copyright holders. Frankly,
> given the current state of the log4j community, I don't see that
> happening.
>
> As I stated before, the java platform is sorely in need of
> consolidation with respect to logging. We are getting there, slowly
> but surely. Nevertheless, it would help if log4j natively adopted the
> SLF4J API. There were many opportunities for this happening. Actually,
> in 2004, SLF4J (called UGLI at the time) was part of log4j.
> Unfortunately, continuous obstructions placed by certain unnamed
> parties for the adoption of SLF4J as log4j's client-facing API was the
> main reason why I personally stopped working on log4j and started the
> logback project instead. Anyway, almost 5 years passed since that
> time, and I my expectations regarding the resolution of this matter
> are rather low. Anyway, it's a different topic altogether...
>
> --
> Ceki
> http://logback.qos.ch: the reliable, generic, fast and flexible logging
> framework.
>
> On 19/02/2010 7:06 PM, Christian Grobmeier wrote:
>>
>> Hi,
>>
>> we had already "copyright" discussion with code from logback in this
>> list. If we would logback - that would mean that we need to incubate
>> it. I think there is an interest here. I am just a little afraid
>> before copyright discussion.
>>
>> So - Ceki, can you help here once again. Sorry for asking dump. From
>> your side, if we would logback - are there any copyright problems we
>> should be aware of before discussion any further? I was thinking on
>> this "prudent" fix I need to dig more in it.
>>
>> Cheers
>> Christian
>>
>> On Fri, Feb 12, 2010 at 6:46 AM, Curt Arnold<ca...@apache.org> wrote:
>>>
>>> On Feb 10, 2010, at 3:44 PM, Gary Gregory wrote:
>>>
>>>> Since logback is licensed under EPL 1, does it matter who brings it to
>>>> Apache? IOW, does the license allow for the code to be copied and repackaged
>>>> as org.apache?
>>>> Gary
>>>
>>> I'm pretty sure that it would require a license grant by each of the
>>> contributors. But that would be a incubator/legal question if that were to
>>> be seriously considered.
>>>
>>> I'll write more the weekend.
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Ceki Gülcü <ce...@qos.ch>.
Christian,
When you say "we would logback", it's not exactly clear what you mean.
Anyway, to answer your question, Logback is dual licensed under LGPL
and EPL per the licensee's choosing. Both licenses are reciprocal,
but the LGPL has a legal clause requiring the client code to authorize
debugging which the ASF does not deem acceptable. LGPL, in ASF
terminology, is an "excluded license". Since logback is EPLed, it can
be used by Apache projects in binary form but with respect to derivative
works, for example if you copy a logback source file and incorporate
it into log4j, the said work would need to be distributed under the
EPL.
Even if logback was licensed under the Apache Software License, you
still can't change the copyright attributions because even the Apache
Software License requires that existing copyright notices be preserved.
For the definition of "reciprocal" and "excluded" as well as other 3rd
party licenses, see
http://www.apache.org/legal/3party.html
In short, copying source code from an open-source project licensed
under any "common" open-source license (GPL, LGPL, ASL, EPL, MPL,
BSD..) *and* removing existing copyright notices is not allowed.
I don't see how one could comfortably import logback into
the ASF without a software grant by the copyright holders. Frankly,
given the current state of the log4j community, I don't see that
happening.
As I stated before, the java platform is sorely in need of
consolidation with respect to logging. We are getting there, slowly
but surely. Nevertheless, it would help if log4j natively adopted the
SLF4J API. There were many opportunities for this happening. Actually,
in 2004, SLF4J (called UGLI at the time) was part of log4j.
Unfortunately, continuous obstructions placed by certain unnamed
parties for the adoption of SLF4J as log4j's client-facing API was the
main reason why I personally stopped working on log4j and started the
logback project instead. Anyway, almost 5 years passed since that
time, and I my expectations regarding the resolution of this matter
are rather low. Anyway, it's a different topic altogether...
--
Ceki
http://logback.qos.ch: the reliable, generic, fast and flexible logging framework.
On 19/02/2010 7:06 PM, Christian Grobmeier wrote:
> Hi,
>
> we had already "copyright" discussion with code from logback in this
> list. If we would logback - that would mean that we need to incubate
> it. I think there is an interest here. I am just a little afraid
> before copyright discussion.
>
> So - Ceki, can you help here once again. Sorry for asking dump. From
> your side, if we would logback - are there any copyright problems we
> should be aware of before discussion any further? I was thinking on
> this "prudent" fix I need to dig more in it.
>
> Cheers
> Christian
>
> On Fri, Feb 12, 2010 at 6:46 AM, Curt Arnold<ca...@apache.org> wrote:
>>
>> On Feb 10, 2010, at 3:44 PM, Gary Gregory wrote:
>>
>>> Since logback is licensed under EPL 1, does it matter who brings it to Apache? IOW, does the license allow for the code to be copied and repackaged as org.apache?
>>> Gary
>>
>> I'm pretty sure that it would require a license grant by each of the contributors. But that would be a incubator/legal question if that were to be seriously considered.
>>
>> I'll write more the weekend.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Christian Grobmeier <gr...@gmail.com>.
Hi,
we had already "copyright" discussion with code from logback in this
list. If we would logback - that would mean that we need to incubate
it. I think there is an interest here. I am just a little afraid
before copyright discussion.
So - Ceki, can you help here once again. Sorry for asking dump. From
your side, if we would logback - are there any copyright problems we
should be aware of before discussion any further? I was thinking on
this "prudent" fix I need to dig more in it.
Cheers
Christian
On Fri, Feb 12, 2010 at 6:46 AM, Curt Arnold <ca...@apache.org> wrote:
>
> On Feb 10, 2010, at 3:44 PM, Gary Gregory wrote:
>
>> Since logback is licensed under EPL 1, does it matter who brings it to Apache? IOW, does the license allow for the code to be copied and repackaged as org.apache?
>> Gary
>
> I'm pretty sure that it would require a license grant by each of the contributors. But that would be a incubator/legal question if that were to be seriously considered.
>
> I'll write more the weekend.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Curt Arnold <ca...@apache.org>.
On Feb 10, 2010, at 3:44 PM, Gary Gregory wrote:
> Since logback is licensed under EPL 1, does it matter who brings it to Apache? IOW, does the license allow for the code to be copied and repackaged as org.apache?
> Gary
I'm pretty sure that it would require a license grant by each of the contributors. But that would be a incubator/legal question if that were to be seriously considered.
I'll write more the weekend.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: Future development of Log4J?
Posted by Gary Gregory <GG...@seagullsoftware.com>.
Since logback is licensed under EPL 1, does it matter who brings it to Apache? IOW, does the license allow for the code to be copied and repackaged as org.apache?
Gary
----
Gary Gregory
ggregory@apache.org
ggregory@seagullsoftware.com
www.seagullsoftware.com
> -----Original Message-----
> From: Christian Grobmeier [mailto:grobmeier@gmail.com]
> Sent: Wednesday, February 10, 2010 10:45
> To: Log4J Developers List
> Subject: Re: Future development of Log4J?
>
> > Another option would be to declare logback as the official successor
> > to log4j, i.e. designate it as log4j 2.0.
>
> yes - that would be the most perfect solution i think. But are you
> willing to do bring the code back to apache?
>
> Cheers
> Christian
>
>
> >
> >> Cheers,
> >> Christian
> >
> > --
> > Ceki
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Ceki Gülcü <ce...@qos.ch>.
On 10/02/2010 7:45 PM, Christian Grobmeier wrote:
>> Another option would be to declare logback as the official successor
>> to log4j, i.e. designate it as log4j 2.0.
>
> yes - that would be the most perfect solution i think. But are you
> willing to do bring the code back to apache?
Sorry, I wasn't very clear. I had meant that the log4j declare logback as
its successor with logback remaining where it is. Bringing logback to Apache was
not on my mind.
Cheers,
--
Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Christian Grobmeier <gr...@gmail.com>.
> Another option would be to declare logback as the official successor
> to log4j, i.e. designate it as log4j 2.0.
yes - that would be the most perfect solution i think. But are you
willing to do bring the code back to apache?
Cheers
Christian
>
>> Cheers,
>> Christian
>
> --
> Ceki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Ceki Gülcü <ce...@qos.ch>.
On 10/02/2010 6:12 PM, Christian Grobmeier wrote:
> Hi all,
>
> I would like to bring up the old discussion on future Log4J
> development again. I think christmas killed it before there was an
> satisfying conclusion. I was basically asking if Log4J is dead or not;
> several opinions rose. There is logback as a stable project,
> implementing the meanwhile wellknown SLF4J API.
>
> Curt showed me a bunch of mails/tickets in Jira for a possible
> redesign of Log4J known as 2.0
>
>
> On Sat, Dec 12, 2009 at 7:33 PM, Curt Arnold<ca...@apache.org> wrote:
>> The JIRA tracker for log4j2 has captured some potential design goals at http://issues.apache.org/jira/browse/LOG4J2.
>>
>> Here are some posts to start as a reading list for the backstory (reverse chronological order):
>>
>> http://marc.info/?l=log4j-user&m=125725041724346&w=2
>> http://marc.info/?t=122830451800001&r=1&w=2
>> http://marc.info/?t=121385743100001&r=1&w=2
>> http://marc.info/?t=121094847000005&r=1&w=2
>>
>> That should be enough to get started as they should contain links to older articles.
>
> Some people thought it might be a good idea to continue because of
> f.e. the Apache community model. Other said that might be a waste of
> time.
>
> Log4J in my opinion is near to the attic, if there is no development
> activity. I would think this would be pretty said and I am willing to
> spend some time. But I cannot lead the development - there are others
> who were involved in tons of discussions in the past.
>
> Question: are some more interested developers subscribed to this list
> who are willing to work on Log4J 2.0 again?
Hello Christian,
Another option would be to declare logback as the official successor
to log4j, i.e. designate it as log4j 2.0.
> Cheers,
> Christian
--
Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Ralph Goers <ra...@dslextreme.com>.
I am also interested in 2.0 (and already have commit rights), but have had very little time. Although Logback is superior to Log4j 1.x I do believe signficant improvements could still be made. In addition, I dislike immensely the benevolent dictatorship model if for no other reason than when Ceki goes on vacation the project does too. If Log4j 2.0 started out as a complete rip-off of Logback (which I wouldn't advocate) I would recommend it over Logback simply for that reason.
Ralph
On Feb 10, 2010, at 1:50 PM, Gary Gregory wrote:
> Yes, I am interested in moving Log4J along to 2.0.
>
> Gary Gregory
> ggregory@seagullsoftware.com
> ggregory@apache.org
> www.seagullsoftware.com
>
>
>> -----Original Message-----
>> From: Christian Grobmeier [mailto:grobmeier@gmail.com]
>> Sent: Wednesday, February 10, 2010 09:13
>> To: Log4J Developers List
>> Subject: Re: Future development of Log4J?
>>
>> Hi all,
>>
>> I would like to bring up the old discussion on future Log4J
>> development again. I think christmas killed it before there was an
>> satisfying conclusion. I was basically asking if Log4J is dead or not;
>> several opinions rose. There is logback as a stable project,
>> implementing the meanwhile wellknown SLF4J API.
>>
>> Curt showed me a bunch of mails/tickets in Jira for a possible
>> redesign of Log4J known as 2.0
>>
>>
>> On Sat, Dec 12, 2009 at 7:33 PM, Curt Arnold <ca...@apache.org>
>> wrote:
>>> The JIRA tracker for log4j2 has captured some potential design goals
>> at http://issues.apache.org/jira/browse/LOG4J2.
>>>
>>> Here are some posts to start as a reading list for the backstory
>> (reverse chronological order):
>>>
>>> http://marc.info/?l=log4j-user&m=125725041724346&w=2
>>> http://marc.info/?t=122830451800001&r=1&w=2
>>> http://marc.info/?t=121385743100001&r=1&w=2
>>> http://marc.info/?t=121094847000005&r=1&w=2
>>>
>>> That should be enough to get started as they should contain links to
>> older articles.
>>
>> Some people thought it might be a good idea to continue because of
>> f.e. the Apache community model. Other said that might be a waste of
>> time.
>>
>> Log4J in my opinion is near to the attic, if there is no development
>> activity. I would think this would be pretty said and I am willing to
>> spend some time. But I cannot lead the development - there are others
>> who were involved in tons of discussions in the past.
>>
>> Question: are some more interested developers subscribed to this list
>> who are willing to work on Log4J 2.0 again?
>>
>> Cheers,
>> Christian
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: Future development of Log4J?
Posted by Gary Gregory <GG...@seagullsoftware.com>.
Yes, I am interested in moving Log4J along to 2.0.
Gary Gregory
ggregory@seagullsoftware.com
ggregory@apache.org
www.seagullsoftware.com
> -----Original Message-----
> From: Christian Grobmeier [mailto:grobmeier@gmail.com]
> Sent: Wednesday, February 10, 2010 09:13
> To: Log4J Developers List
> Subject: Re: Future development of Log4J?
>
> Hi all,
>
> I would like to bring up the old discussion on future Log4J
> development again. I think christmas killed it before there was an
> satisfying conclusion. I was basically asking if Log4J is dead or not;
> several opinions rose. There is logback as a stable project,
> implementing the meanwhile wellknown SLF4J API.
>
> Curt showed me a bunch of mails/tickets in Jira for a possible
> redesign of Log4J known as 2.0
>
>
> On Sat, Dec 12, 2009 at 7:33 PM, Curt Arnold <ca...@apache.org>
> wrote:
> > The JIRA tracker for log4j2 has captured some potential design goals
> at http://issues.apache.org/jira/browse/LOG4J2.
> >
> > Here are some posts to start as a reading list for the backstory
> (reverse chronological order):
> >
> > http://marc.info/?l=log4j-user&m=125725041724346&w=2
> > http://marc.info/?t=122830451800001&r=1&w=2
> > http://marc.info/?t=121385743100001&r=1&w=2
> > http://marc.info/?t=121094847000005&r=1&w=2
> >
> > That should be enough to get started as they should contain links to
> older articles.
>
> Some people thought it might be a good idea to continue because of
> f.e. the Apache community model. Other said that might be a waste of
> time.
>
> Log4J in my opinion is near to the attic, if there is no development
> activity. I would think this would be pretty said and I am willing to
> spend some time. But I cannot lead the development - there are others
> who were involved in tons of discussions in the past.
>
> Question: are some more interested developers subscribed to this list
> who are willing to work on Log4J 2.0 again?
>
> Cheers,
> Christian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Christian Grobmeier <gr...@gmail.com>.
Hi all,
I would like to bring up the old discussion on future Log4J
development again. I think christmas killed it before there was an
satisfying conclusion. I was basically asking if Log4J is dead or not;
several opinions rose. There is logback as a stable project,
implementing the meanwhile wellknown SLF4J API.
Curt showed me a bunch of mails/tickets in Jira for a possible
redesign of Log4J known as 2.0
On Sat, Dec 12, 2009 at 7:33 PM, Curt Arnold <ca...@apache.org> wrote:
> The JIRA tracker for log4j2 has captured some potential design goals at http://issues.apache.org/jira/browse/LOG4J2.
>
> Here are some posts to start as a reading list for the backstory (reverse chronological order):
>
> http://marc.info/?l=log4j-user&m=125725041724346&w=2
> http://marc.info/?t=122830451800001&r=1&w=2
> http://marc.info/?t=121385743100001&r=1&w=2
> http://marc.info/?t=121094847000005&r=1&w=2
>
> That should be enough to get started as they should contain links to older articles.
Some people thought it might be a good idea to continue because of
f.e. the Apache community model. Other said that might be a waste of
time.
Log4J in my opinion is near to the attic, if there is no development
activity. I would think this would be pretty said and I am willing to
spend some time. But I cannot lead the development - there are others
who were involved in tons of discussions in the past.
Question: are some more interested developers subscribed to this list
who are willing to work on Log4J 2.0 again?
Cheers,
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Future development of Log4J?
Posted by Curt Arnold <ca...@apache.org>.
On Dec 11, 2009, at 3:50 AM, Christian Grobmeier wrote:
> Hi all,
>
> I looked at the svn of Log4J and saw that there is no activity on the
> 2.0 branch for 17 months.
...
>
> Since there is less activity at all, I would like to know about your
> thoughts on the future development. I saw no posts at this topic at
> all. However, I strongly believe that with cleaning up Log4J lots
> could be won. I don't want to to step on anybodys tooth, but I think
> the project needs to refactor it's stuff, not caring about backwards
> compatiblity. Clean up the old deprecations and everything which was
> necessary to keep performance on old JDKs, but no longer.
>
I'm not sure I understand "no posts at all", there are severals pages of matches if you search the log4j-dev archives for "log4j 2.0". Making sense of all the posts is more the problem. The JIRA tracker for log4j2 has captured some potential design goals at http://issues.apache.org/jira/browse/LOG4J2.
Here are some posts to start as a reading list for the backstory (reverse chronological order):
http://marc.info/?l=log4j-user&m=125725041724346&w=2
http://marc.info/?t=122830451800001&r=1&w=2
http://marc.info/?t=121385743100001&r=1&w=2
http://marc.info/?t=121094847000005&r=1&w=2
That should be enough to get started as they should contain links to older articles.
I'll continue some thoughts after lunch.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org