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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
> 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/
