Hi Ceki,
Are you sure that this conflict is unavoidable? It would be great if
all of the methods present in the original log4j Logger could be
represented in the nlog4j implementation (down to identical method
arguments). It was my understanding that we were seeing this issue
because some of the arguments had changed in nlog4j.
I think slf4j loses quite a bit of 'adoptability' by not being able
to function alongside log4j.
On 11/10/2005, at 12:59 AM, Ceki Gülcü wrote:
As you say, NLOG4J requiring NLOG4J has been previously stated. As
for the class path requirement, it's kind of an obvious and basic
housekeeping chore. Isn't it *always* unsafe to have distinct versions
of a library present on the class path?
Well, yes and no. While it is healthy, for many reasons, to prevent
duplication of classes on the classpath, it has never been a problem
to have two distinct versions of log4j on the classpath. At least,
I've never found it to be a problem. Now we have introduced mandatory
housekeeping. :) I know that quite a few administrators will just ask
people to use log4j, instead of SLF4J.
I see why replacing one jar with another might be impossible under
certain circumstances. It's an additional step that needs to be
performed which one might consider as unnecessary hassle.
Well, there is now an issue of 'accessibility of adoption', or
something like that.
The classpath conflict is not so much an unnecessary hassle as a
prohibition. Some managers won't risk the smooth running of
enterprise applications just to upgrade a logging framework,
especially if the existing one is running well.
Without that upgrade, ApacheDS won't see the light of day, in
embedded use-cases, for such applications.
Cheers,
Nick
