jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Sedding (Jira)" <j...@apache.org>
Subject [jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
Date Sun, 10 May 2020 21:17:00 GMT

    [ https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17103950#comment-17103950

Julian Sedding commented on OAK-9024:

My bottom line is: *{{oak-solr-osgi}} MUST import {{org.slf4j.impl}}* in order for the logging
to work correctly.

[~baedke], I get the impression (and I don't mean this personally, so my apologies if I am
wrong) that you don't fully separate the Maven class-path and the bundle's class-path in OSGi.
The bnd tool (here in the form of the maven-bundle-plugin IIRC) is concerned with making sure
that the bundle has a consistent class-space. That consists of two major parts: (a) all packages
(and classes) inside the bundle and (b) all packages (and classes) that need to be provided
to the bundle from the outside, i.e. everything listed in {{Import-Package}}.

The bnd tool computes a graph of dependencies between classes using static byte-code analysis.
That means it just uses what it can find on the class-path, but does not care about dependencies
defined in Maven otherwise. Notably, it ignores available Java packages for the {{Import-Package}}
computation, if they are not statically reachable via the classes inside the bundle (i.e.
they aren't needed). This mechanism would obviously miss any classes that are loaded manually
using a String class-name.

A consequence of embedding the {{slf4j-log4j12}} artifact is that on the package level you
embed {{org.slf4j.impl}} (and others I believe). Since that package is now inside the bundle,
bnd can remove it from the {{Import-Package}} header. The same can be achieved by embedding
any other artifact that contains {{org.slf4j.impl}}, of which there are quite a few.

Now the but. But slf4j's contract for bindings seems to be that each binding defines {{org.slf4j.impl.StaticLoggerBinder}},
which essentially makes this an SPI. In Sling-based setups there is an {{slf4j.api}} bundle
and an {{org.apache.sling.commons.log}} bundle (the binding used in Sling). Notably, the {{slf4j.api}}
bundle imports the package {{org.slf4j.impl}} from {{org.apache.sling.commons.log}}. That
is because essentially {{org.slf4j.impl}} is the SPI that SLF4J uses to connect the logging
API with a binding.

Furthermore, I am under the impression that SLF4J only supports a single binding in a deployment.
This would make embedding {{slf4j-log4j12}} in {{oak-solr-osgi}} problematic, because (a)
it would introduce a second binding in Sling-based setups and (b) it would eliminate the possibility
to swap out logging bindings. Regarding (a) my guess would be that at least log messages might
get lost (there's no log4j present that would actually write the logs) or possibly more obvious

I think it is a little bit odd for SLF4J to call the package that hooks in the bindings {{impl}}.
However, once we ignore this suggestive name, there is no reason why {{oak-solr-osgi}} should
not import {{org.slf4j.impl}}. (Of course there would be good reasons for Solr to avoid directly
calling into SLF4J's bindings SPI, but that's out-of-scope for Oak).

So that's why my bottom line is: {{oak-solr-osgi}} MUST import {{org.slf4j.impl}} in order
for the logging to work correctly.

Still, I think it would be better to control the import version range for {{org.slf4j.impl}}.
At the moment, I believe that it just "happens" to be whatever we get transitively from Zookeeper
or Solr or elsewhere. Controlling the version range could be achieved by declaring a provided
dependency on e.g. {{slf4j-simple}}. Maybe with a comment that it is only used to help bnd
compute the correct version range.

> oak-solr-osgi imports org.slf4j.impl
> ------------------------------------
>                 Key: OAK-9024
>                 URL: https://issues.apache.org/jira/browse/OAK-9024
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: solr
>            Reporter: Julian Reschke
>            Assignee: Manfred Baedke
>            Priority: Minor
>             Fix For: 1.28.0
>         Attachments: OAK-9024.patch
> From the manifest:
> {{org.slf4j.impl;version="[1.6,2)"}}

This message was sent by Atlassian Jira

View raw message