You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Piotr Karwasz (Jira)" <ji...@apache.org> on 2022/07/01 07:09:00 UTC
[jira] [Comment Edited] (LOG4J2-3545) Log4J-JCL should have the same OSGI configuration as Log4j-SLF4J18
[ https://issues.apache.org/jira/browse/LOG4J2-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17561185#comment-17561185 ]
Piotr Karwasz edited comment on LOG4J2-3545 at 7/1/22 7:08 AM:
---------------------------------------------------------------
Hi [~jcompanger@gmail.com],
I have added the Service Loader Mediator capabilities to the latest {{2.18.1-SNAPSHOT}} (as optional capability). Can you check if it suits your purpose and explain how do you intend to use it?
While testing your solution with the latest Apache Aries SPI Fly, I encountered two problems:
* Commons Logging does not use {{{}ServiceLoader.load{}}}, but looks up the {{META-INF/services/org.apache.commons.logging.LogFactory}} resource directly. That is why it can not be used with the standard Service Loader Mediator,
* while using the SPI Fly extensions to the Service Loader Mediator specification (notably {{{}SPI-Consumer: org.apache.commong.logging.LogFactory#getFactory(){}}}) the weaving failed, because Commons Logging uses a very old Java 1.2 class file format.
Until one of these problems is solved, I don't see how you can easily use {{log4j-jcl}} in an OSGI environment.
There is however another solution: we could include the package {{org.apache.commons.logging}} into {{log4j-jcl}} itself and change the default {{LogFactory}} to use Log4j2. Basically that is what {{spring-jcl}} and {{pax-logging-api}} do. This should work smoothly, when running in an OSGI container or on the classpath, but will fail with JPMS. [~rgoers] and [~ggregory], what do you think?
was (Author: pkarwasz):
Hi [~jcompanger@gmail.com],
I have added the Service Loader Mediator capabilities to the latest {{2.18.1-SNAPSHOT}} (as optional capability). Can you check if it suits your purpose and explain how do you intend to use it?
While testing your solution with the latest Apache Aries SPI Fly, I encountered two problems:
* Commons Logging does not use {{{}ServiceLoader.load{}}}, but looks up the {{META-INF/services/org.apache.commons.logging.LogFactory}} resource directly. That is why it can not be used with the standard Service Loader Mediator,
* while using the SPI Fly extensions to the Service Loader Mediator specification (notably {{{}SPI-Consumer: org.apache.commong.logging.LogFactory#getFactory(){}}}) the weaving failed, because Commons Logging uses a very old Java 1.2 class file format.
Until one of these problems is solved, you don't see how you can easily use {{log4j-jcl}} in an OSGI environment.
There is however another solution: we could include the package {{org.apache.commons.logging}} into {{log4j-jcl}} itself and change the default {{LogFactory}} to use Log4j2. Basically that is what {{spring-jcl}} and {{pax-logging-api}} do. This should work smoothly, when running in an OSGI container or on the classpath, but will fail with JPMS. [~rgoers] and [~ggregory], what do you think?
> Log4J-JCL should have the same OSGI configuration as Log4j-SLF4J18
> ------------------------------------------------------------------
>
> Key: LOG4J2-3545
> URL: https://issues.apache.org/jira/browse/LOG4J2-3545
> Project: Log4j 2
> Issue Type: Improvement
> Components: JCL Bridge
> Affects Versions: 2.17.2
> Reporter: Johan Compagner
> Priority: Major
>
> if you look at the manifest in this jar:
> [https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-jcl/2.17.2/log4j-jcl-2.17.2.jar]
> compared to the one that is in here:
> [https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-slf4j18-impl/2.17.2/log4j-slf4j18-impl-2.17.2.jar]
>
> then slf4j has the right OSGI manifest entries to work correctly with the ServiceLoader
> SLF4j has:
>
> Require-Capability: osgi.extender;filter:="(osgi.extender=osgi.service
> loader.registrar)",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> Provide-Capability: osgi.serviceloader;osgi.serviceloader="org.slf4j.s
> pi.SLF4JServiceProvider"
>
> JCL has:
>
> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
>
> this should become to fully support it in an OSGi environment:
>
> Require-Capability: osgi.extender;filter:="(osgi.extender=osgi.servicelo
> ader.registrar)",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> Provide-Capability: osgi.serviceloader;osgi.serviceloader="org.apache.commons.logging.LogFactory"
>
> to follow the spec: [133 Service Loader Mediator Specification - OSGi Enterprise 7|https://docs.osgi.org/specification/osgi.enterprise/7.0.0/service.loader.html]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)