Yes, in standalone mode it isn't an issue.
For embedded, you could switch your underlying implementation if needed. It would, however, be against the very purpose of the SLF4J facade to adopt a secondary logging frameworking by switching to a slf4j alternative logger because your logging library of choice was log4j!
Also, it introduces some policing to ensure that nlog4j and log4j are not on the same classpath. It's another factor which could be gotten wrong.
As Emmanuel said in reply to your email, Ceki is thinking on this right now.
On 13/10/2005, at 5:34 AM, Jérôme Baumgarten wrote:
On 10/12/05, Nick Faiz <firstname.lastname@example.org> wrote:
Okay. I understand that it might seem like a noisy chat about SLF4J,
My motive is simple. I am only concerned about logging for ApacheDS.
It has become an ApacheDS issue.
> - third, I think that Ceki did a lot of good job, he also really
> us, and I don't want him to think that we think that log4j is a
> pile of
If you go for SLF4J, wouldn't that resolve your problem. For running in a standalone more, you then can choose whatever SLF4J version you want, the one using Simple-Log or nlog4j. Using ApacheDS embedded in another application, you can also choose the most appropriate SLF4J version. If you may get into troubles because of log4j then you go for the Simple-Log based SLF4J. This could easily be resolved by externalizing the logging jar.