You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@manifoldcf.apache.org by Markus Schuch <ma...@deutschebahn.com> on 2019/03/05 13:35:36 UTC
Log Framework Zoo
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
AW: Log Framework Zoo
Posted by Markus Schuch <ma...@deutschebahn.com>.
Hi Karl,
> The ManifoldCF code itself has all been migrated to log via Log4J 2. As I said before, we have dependencies though that do not go that route.
Our own Logging classes actually still use Log4J 1 API. Logging is adapted (at runtime) by the log4j-1.2-api-2.4.1.jar.
https://github.com/apache/manifoldcf/blob/ec330a7261c7ca6a3362dcf1358ddf95cf4991d0/framework/core/src/main/java/org/apache/manifoldcf/core/system/Logging.java#L25
We might consider migrating our own logging code to use the actual Log4J 2 API + Core (Core is needed for the programmatic configuration).
Without the log4j-1.2-api adapter, it is no longer a problem to have log4j 1 around for the other dependencies.
Cheers,
Markus
________________________________
Pflichtangaben anzeigen<http://www.deutschebahn.com/pflichtangaben/20190306>
Nähere Informationen zur Datenverarbeitung im DB-Konzern finden Sie hier: http://www.deutschebahn.com/de/konzern/datenschutz
Re: Log Framework Zoo
Posted by Markus Schuch <ma...@web.de>.
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 <ma...@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
>>
>
Re: Log Framework Zoo
Posted by Karl Wright <da...@gmail.com>.
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 <ma...@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
>