directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [apacheds] Which logging framework?
Date Thu, 30 Jun 2005 12:17:43 GMT
Hiya,

I've finally gone through all the literature out there.  CL is full of 
pitfalls and should be avoided period.  Log4J is robust and the oldest 
logging framework we have.  It's mature, very commonly used and there's 
no need for another API.  We'll just use Log4J straight for now. 

Later we can create a custom RepositorySelector to make it work in 
containers.  I think the RS we use should be based on SystemPreferences 
rather than JNDI.

Nick Faiz wrote:

> Hi,
>    My own inclinations would be to take the framework with least 
> complexity - log4j. No one seems to write articles about how log4j is 
> difficult and has resource loading issues. The patch works and lays 
> the ground for putting in proper logging. Commons logging seems to 
> have known problems: for example, 
> http://www.qos.ch/logging/thinkAgain.jsp .

Yep just got through these.

>    I also think planning needs to be put into (a) how logging will 
> cooperate with a container, in an embedded situation and (b) what kind 
> of logging the server will offer in general through an administrative 
> interface. The last point, b, is more complex but can still be catered 
> for by log4j.

I think the key to this rests in how we deal with Log4J 
RepositorySelectors.  I'm thinking we could use system preferences to 
determine how to select the heirarchy used by Log4J.  Ceki has some good 
examples of using JNDI here:

http://www.qos.ch/logging/sc.jsp

>    I'm saying this objectively. The patch took me an hour or so to 
> create, Im not really hung up on using it. I just think log4j has the 
> path of least resistance here. Really, Id like to see logging added, 
> that's all. :)
>
Agreed! After reading up and researching this Log4J is all we need.  
Let's not complicate this any further.  It's looking like we're all 
navigating towards Log4j as this thread continues to shed more light on 
the problems with CL.

Is there a need for a vote or can we just close this thread and use Log4J?

Alex

>
> Trustin Lee wrote:
>
>> Hi,
>>
>> 2005/6/29, Emmanuel Lecharny <elecharny@apache.org 
>> <mailto:elecharny@apache.org>>:
>>
>>     > The Directory Server is not an app server, but do keep in mind
>>     that when we are embedding, the better citizen that we can be in
>>     that embedded environment, the better.  And we also have
>>     components of our own, since as triggers, stored procedures, etc.
>>
>>     Guys, actually a lot of the Apache DS code is based on commons-log,
>>     other parts rely on java.util.logging, and the remaining use log4j.
>>
>>  
>> I believe ApacheDS can be used for both embedded and standalone 
>> purporse eventually.
>>
>>     >From *my* point of view, log4j is perfect for what we are doing
>>     actually.
>>
>>     Now, answering Trustin question, using java.util.logging doesn't 
>> seems
>>     *to me* a very good idea. It has the same drawback than log4j - cf
>>     Marc
>>     & Noel answers - and it does not compare with log4j in term of
>>     fonctionality, or tooling.
>>
>>  
>> It looks like java.util.logging is less convinient than Log4J or 
>> Commons-Logging.
>>
>>     If I have to make a choice, based on what ApacheDS will be in two
>>     years,
>>     it may be :
>>     1) commons-logging/Juli + log4j
>>     2) log4j
>>     3) java.util.logging
>>
>>  
>> If commons logging team is fixing the issue Stephane addressed as 
>> Noel mentioned, I'd like to go to the choice #1 because I believe 
>> commons logging is widely deployed and almost everyone knows how to 
>> use it.
>>  
>> Actually I don't think the dynamic loading issue is not really 
>> critical because we already know about it IMHO.
>>  
>> Trustin
>> -- 
>> what we call human nature is actually human habit
>> -- 
>> http://gleamynode.net/
>
>
>
>


Mime
View raw message