avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: LogKit and Log4J Discussion
Date Wed, 20 Jun 2001 18:32:11 GMT
On Thu, 21 Jun 2001 03:03, Ceki Gülcü wrote:
> I should not have accused you of copying in a public forum. It was improper
> and I sincerely apologize for that.


> I regret to frequently read notes signed by you attacking log4j. 

It's not an attack. I do not say anything false (at least that I am aware 
of). I tend not to give much opinion except that I think client interface is 
better designed. The rest is just statistics. If you fell that I am wrong (ie 
Log4j has fewer lines of code or is faster or is secure by design) then prove 
it ;) If you can't handle what I say then you should "fix" Log4j so what I 
say is not true or get thicker skin.

>I do not
> think one can find a single example, in public or in private, where I
> criticize LogKit, not one.

I for one would prefer you criticize LogKit (based on technical merits). That 
would be far better than what happened here today.

> - Log4j supported configuration files since ages. We are planning to add a
> management interface in log4j version 1.2. I don't see what you mean by
> dynamic configuration 

When first decided to come to Jakarta, Stefano emailed me and said "lets use 
this for Avalon". I looked and found that the code was fine if you configure 
once at start of application. However you couldn't reconfigure while the 
application was in motion. You later fixed this in one of the 0.8.... 
releases IIRC (not sure the ChangeLog should be in Avalon mail archive). I 
presumed this was because I asked for it and pointed out it's usefulness in 

>and how it applies to taking away your ideas without recognition.

I don't care about recognition - personally I would strip out all author tags 
on the projects I work on ;) What I do care about is you accusing me of being 
parasitic on log4j community. It seemed hyprocritical to accuse me of copying 
when as far as I can see the only copying I have done is changing to match 
Log4Js names for Hierarchy and LogEvent. Combine that with the fact that  I 
spent a fair bit of time looking over the source and sending you 
recomendations earlier on in process.

> - Although some fields have changed in LoggingEvent, its serialization has
> remained the same as long as I can remember. Again, I do not see how this
> relates to the log4j project copying your idea without giving recognition.

Earlier you did the serialization/rendering of message early on logging 
pipeline. At the same time you added Filters you added better support for 
delaying this serialization/rendering.

> - Filters were suggested by many people not just you. I assume you do not
> want recognition for this do you?

Filters where implemented in Log4j a few weeks after I mentioned how useful 
they were in LogKit. I don't care about recognition but don't try to claim I 
stole this idea from you.

> >However trying to get him to change anything else was impossible. Then I
> >attempted to encourage to join together and do a "revolution". Both LogKit
> >and Log4j have errors in them and we could eliminate them - he refused.
> > Then I tried to get him to at least to agree on common backend (ie
> > Appenders, Events etc) - he never replied. The only reason that LogKit
> > remains is because Log4j is unsuitable for our use - and Ceki was not
> > interested in cooperating to fix it.
> I am very interested in cooperation and exchange of ideas. I do not recall
> any proposal for a common backend. I am not saying that you did not send
> it. I just have not received it.

hmm - that could explain why you never replied ;)

> Would you have a copy of this proposal?

Possibly. It will be in my mail archives somewhere ... basically it was to 
unify LogTargets/Appenders, LogEvents and Formatter/Layout. I am not sure if 
it will be possible (or if possible useful) but it was something. 

> >> What I would like to see in the near future is a Logger interface that
> >> both projects can aggree to so that people who develop in Avalon can use
> >> their logger of choice. If JDK 1.4 supplies such an interface it might
> >> be worth investigating.
> >
> >Never happen - not technically viable.
> The logging API in JDK 1.4 is botched.

Well thats something we agree on. It had too many cooks stirring the pot IMO 
- which is why it ended up with the assortment/duplication of features it 
has. It's one killer feature is that it will be shipped with the JVM ;)



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

View raw message