jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Reschke (Jira)" <j...@apache.org>
Subject [jira] [Comment Edited] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
Date Fri, 08 May 2020 09:47:00 GMT

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

Julian Reschke edited comment on OAK-9024 at 5/8/20, 9:46 AM:
--------------------------------------------------------------

[~baedke] I posted my comment, because I prefer to understand an issue before it is fixed.
I didn't get the impression that it was clear where the slf4j.impl import came from, nor why
(exactly) embedding slf4j-log4j12 seems to fix it.

Assuming that {{org.slf4j.impl.StaticLoggerBinder}} is never actually called, embedding slf4j-log4j12
would be fine. However, I would then rather chose to include slf4j-nop, which has no dependencies
other than slf4j.api. In case the class {{org.slf4j.impl.StaticLoggerBinder}} is never loaded,
excluding org.slf4j.impl from the imports would also be ok.

If {{org.slf4j.impl.StaticLoggerBinder}} is called, I think the situation is more problematic.
The Oak setups I know of (all Sling based) use an OSGi wrapped logback-classic (org.apache.sling.commons.log),
which exports {{org.slf4j.impl}}. For this scenario, I think importing it would be the best
solution. Embedding any other binding may well lead to class loading issues in OSGi.

So I think embedding slf4j-log4j12 may not solve the problem, or may only solve it superficially.
I would actually lean towards importing {{org.slf4j.impl}}, maybe adjusting the version range
(if necessary) and linking back to this issue from the POM to document this oddity.


was (Author: jsedding):
[~baedke] I posted my comment, because I prefer to understand an issue before it is fixed.
I didn't get the impression that it was clear where the slf4j.impl impoprt came from, nor
why (exactly) embedding slf4j-log4j12 seems to fix it.

Assuming that {{org.slf4j.impl.StaticLoggerBinder}} is never actually called, embedding slf4j-log4j12
would be fine. However, I would then rather chose to include slf4j-nop, which has no dependencies
other than slf4j.api. In case the class {{org.slf4j.impl.StaticLoggerBinder}} is never loaded,
excluding org.slf4j.impl from the imports would also be ok.

If {{org.slf4j.impl.StaticLoggerBinder}} is called, I think the situation is more problematic.
The Oak setups I know of (all Sling based) use an OSGi wrapped logback-classic (org.apache.sling.commons.log),
which exports {{org.slf4j.impl}}. For this scenario, I think importing it would be the best
solution. Embedding any other binding may well lead to class loading issues in OSGi.

So I think embedding slf4j-log4j12 may not solve the problem, or may only solve it superficially.
I would actually lean towards importing {{org.slf4j.impl}}, maybe adjusting the version range
(if necessary) and linking back to this issue from the POM to document this oddity.

> 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
(v8.3.4#803005)

Mime
View raw message