manifoldcf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Schuch <markus_sch...@web.de>
Subject Re: Log Framework Zoo
Date Wed, 06 Mar 2019 07:30:55 GMT
Hi Karl,

thanks for explaining why log4j 1.2 is still a dependency for us.

I understand removing log4j 1.2 is not easy or probably not possible at
the moment. I also have no intention to rush anything here.

But the issue with having both log4j.jar and log4j-1.2-api.jar remains.
Both JARs contain the same classes with different implementation and if
- for whatever reason - the classloader order changes, the outcome will
be different.

Recently i had a hard time to gather diagnostics logging. The logger was
definetly on level DEBUG (inspected with remote debugging) but still did
not log anything in some of our environments. After activating the
verbose output of log4j and log4j 2 we saw, that in the affected
environments the ManifoldCF logging initialization triggered the log4j 1
stack, in the other environment the adapter for log4j 2 was used and the
log4j2 stack was initialized.

Do you remember what parts are dependant on log4j-1.2-api.jar. Is it
just to adapt our logging code to log4j 2.x? If yes, did you try to
migrate our logging code to log4j 2.x API? If this is possible we could
get rid of log4j-1.2-api.jar.
Having both log4j 1 and 2 in a classpath would be fine. It is just the
overlap of classes that concerns me.

Thanks,
Markus


Am 05.03.2019 um 14:55 schrieb Karl Wright:
> Two years ago I moved the standard logger for all of ManifoldCF to log4j
> 2.  This was a non-backwards-compatible change but it was forced on us
> because our downstream connector dependencies started to require it.
> 
> However, there are still log4j 1.2 dependencies we cannot get rid of due to
> other packages (like Jetty and Zookeeper) that haven't yet upgraded.  So
> they all have to coexist together.
> 
> It was a major chunk of work getting everything to run after this was
> done.  I would suggest being *very* careful about removing dependencies
> even if you think they're not doing anything.
> 
> Thanks,
> Karl
> 
> 
> 
> On Tue, Mar 5, 2019 at 8:43 AM Markus Schuch <markus.schuch@deutschebahn.com>
> wrote:
> 
>> Hi,
>>
>> currently we have
>>
>>
>>   *   log4j-1.2.17.jar (Log4j 1 API & Impl)
>>   *   log4j-1.2-api-2.4.1.jar (Log4j 1 API to Log4j 2 Adapter)
>>   *   log4j-api-2.4.1.jar (Log4j 2 API)
>>   *   log4j-core-2.4.1.jar (Log4j 2 Impl)
>>   *   commons-logging-1.2.jar (Commons Logging API)
>>   *   jcl-over-slf4j-1.7.25.jar (Replacement for Commons Logging with
>> SLF4j in the stomach)
>>   *   slf4j-api-1.7.25.jar (SLF4J API)
>>   *   slf4j-simple-1.7.25.jar (Simple SLF4J Impl)
>>
>>
>> on our Classpath.
>>
>> I see the following problems:
>>
>>   *   Having both log4j-1.2.x.jar and log4j-1.2-api-2.x.jar is kind of
>> classloader roulette since both JARs contain the log4j 1.2 API packages and
>> classes with different implementation
>>   *   The same goes for commons-logging and jcl-over-slf4j
>>   *   Log statements from SLF4J are logged with a different logger, that
>> everything else
>>
>> I would suggest to (without having tried to compile it)
>>
>>   *   remove log4j-1.2.17.jar
>>   *   remove commons-logging-1.2.jar
>>   *   remove slf4j-simple-1.7.25.jar
>>   *   add log4j-slf4j-impl-2.4.1.jar (as replacement for slf4j-simple)
>>
>> But may be there are other historic reasons for having all those JARs
>> around.
>>
>> Has somebody more insights on that?
>>
>> Many thanks in advance,
>> Markus
>>
>>
>> ________________________________
>>
>> Pflichtangaben anzeigen<
>> http://www.deutschebahn.com/pflichtangaben/20190304>
>>
>> N?here Informationen zur Datenverarbeitung im DB-Konzern finden Sie hier:
>> http://www.deutschebahn.com/de/konzern/datenschutz
>>
> 

Mime
View raw message