[logback-user] Legacy Log4j Question

[Ceki Gulcu]

Yes, I am flip-flopping.

On 27.10.2010 16:15, Ceki Gulcu wrote:
> On 27.10.2010 15:08, Robert Elliot wrote:
>  > Ceki's said in the past that the answer is no. After all, what would
>  > it do? You have to bear in mind that it's intended to redirect log4j
>  > to slf4j - so it has to be slf4j implementation agnostic. So it can't
>  > actually *do* anything with programmatic attempts to change the levels
>  > of Logger instances or add Appenders, the most you could have is a no
>  > operation implementation. That would probably result in loads of null
>  > pointer exceptions as your dependent jars try to use objects retrieved
>  > via the API, not to mention that if your dependent jars actually need
>  > to do these things then they will be broken even if no exception is
>  > thrown immediately.
>
> Indeed I have said as much in the past. However, if users are willing
> to go through the trial and error process, I think we could add more
> missing classes and/or methods with NOP implementations. As long as
> the caller is satisfied with nop, things should be OK.
>
>  > (One possibility I could see is adding all the classes and methods to
>  > be binary compatible but making all the methods throw an
>  > UnsupportedOperationException explaining why log4j-over-slf4j only
>  > implements a small subset of log4j's API so that people aren't left
>  > wondering about ClassNotFoundExceptions - which might have saved you
>  > having this conversation, but wouldn't actually solve your problem.)
>
> NOP could be a viable alternative.
>
>  > If you have a hard dependency on log4j that you can't change then I
>  > guess you have to use log4j.
>
> I agree but may be the caller could be satisfied with NOP.
>
> It should be possible to satisfy most callers except perhaps in
> certain cases which could become rather hard to diagnose due to the
> NOP trickery...
>
>> ----- Original Message -----
>>> From: "Jeremy Truelove"<Jeremy.Truelove at barclayscapital.com>
>>> To: logback-user at qos.ch
>>> Sent: Wednesday, 27 October, 2010 1:58:27 PM
>>> Subject: Re: [logback-user] Legacy Log4j Question
>>> Unfortunately I don't have the ability to change these dependencies
>>> and I don't know why they are coded in the way they are so they have
>>> such a hard dependency on log4j. Is there any plan to add the rest of
>>> the classes to log4j-over-slf4j just to support legacy jar dependency
>>> issues?
>>>
>>> -----Original Message-----
>>> From: logback-user-bounces at qos.ch [mailto:logback-user-bounces at qos.ch]
>>> On Behalf Of Robert Elliot
>>> Sent: Wednesday, October 27, 2010 8:46 AM
>>> To: logback users list
>>> Subject: Re: [logback-user] Legacy Log4j Question
>>>
>>> The question has to be why do your dependent jars need to call these
>>> APIs in log4j? Unfortunately log4j does not differentiate between the
>>> interface for firing off log events (the sort of thing SLF4J/Commons
>>> logging provide) and its API for managing what is actually done for
>>> them. As a general rule libraries should only be using the bare
>>> minimum of logging (the equivalent of the SLF4J interface - which is
>>> what log4j-over-slf4j implements) and only the end user application
>>> should be defining things like appenders and turning logging on or
>>> off.
>>>
>>> If your dependent jars are using the log4j API for controlling what is
>>> done with logging events then either they have a real dependency on
>>> log4j for some good reason or else they are behaving badly. Without
>>> knowing what these dependencies are, what they are doing and why
>>> there's not much else can be said.
>>>
>>> (Of course you always have the option of using log4j as your slf4j
>>> implementation via slf4j-log4j; you can still pipe JULI& Commons
>>> Logging to SLF4J and use SLF4J in your own code and so end up with a
>>> single logging config file, just a log4j one rather than a logback
>>> one.)
>>>
>>> ----- Original Message -----
>>>> From: "Jeremy Truelove"<Jeremy.Truelove at barclayscapital.com>
>>>> To: logback-user at qos.ch
>>>> Sent: Wednesday, 27 October, 2010 1:30:22 PM
>>>> Subject: [logback-user] Legacy Log4j Question
>>>> So I've been porting some of our services to use Logback over log4j
>>>> and I've been using the log4j-over-slf4j jar to spoof log4j for our
>>>> legacy dependencies. The only issue is log4j-over-slf4j doesn't
>>>> implement many of the classes of log4j so I'm seeing a decent few
>>>> class not found exceptions from dependent jars. How have people got
>>>> around this? Is it enough to just put the nlog4j in your classpath
>>>> instead of the log4j-over-slf4j jar? I’d still like to use one
>>>> logback
>>>> config file to drive all my logging to a single log file. Thanks.
>>>>
>>>> jt
>>>>