[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17783603#comment-17783603
]
Manfred Baedke commented on OAK-9024:
-
Not the case anymore.
> 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
> Attachments: OAK-9024.patch
>
>
> From the manifest:
> {{org.slf4j.impl;version="[1.6,2)"}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
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 errors.
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
(v8.3.4#803005)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17100821#comment-17100821
]
Manfred Baedke commented on OAK-9024:
-
[~jsedding],
bq. I don't think embedding a logging binding was ever the goal of
oak-solr-osgi. If you are interested in the original reasoning why this bundle
was created, the discussion https://markmail.org/thread/5xsyx5l4c6euqtt2 may be
interesting.
Yes, we went with option 2 mentioned there, which only confirms that we need to
embed all the transitive runtime dependencies.
> 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)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17100809#comment-17100809
]
Manfred Baedke commented on OAK-9024:
-
[~jsedding], maybe I'm completely missing something, but if we embed zookeeper
and do not embed org.slf4j.slf4j-log4j12, we'd have to make sure by code
inspection that zookeeper will continue working. And every time we update the
zookeeper dependency, we'd have to verify that again. That's a maintenance hell.
> 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)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17100554#comment-17100554
]
Julian Sedding commented on OAK-9024:
-
[~baedke] I performed a simple test. In the pom of the oak-solr-osgi module I
prevent the zookeeper dependency from being embedded by changing the dependency
scope to "provided". Then I created a diff of the Import-Package statement of
the oak-solr-osgi bundle before and after this change.
{noformat}
14d13
< com.ibm.security.krb5.internal {resolution:=optional}
42,44d40
< javax.security.auth
< javax.security.auth.callback
< javax.security.auth.kerberos
46d41
< javax.security.auth.spi
48d42
< javax.security.sasl
135d128
< org.apache.log4j.jmx {resolution:=optional,
version=[1.2,2)}
156a150,154
> org.apache.zookeeper {version=[3.4,4)}
> org.apache.zookeeper.data {version=[3.4,4)}
> org.apache.zookeeper.server{version=[3.4,4)}
> org.apache.zookeeper.server.auth {version=[3.4,4)}
> org.apache.zookeeper.server.quorum {version=[3.4,4)}
166,170d163
< org.jboss.netty.bootstrap {resolution:=optional,
version=[3.7,4)}
< org.jboss.netty.buffer {resolution:=optional,
version=[3.7,4)}
< org.jboss.netty.channel{resolution:=optional,
version=[3.7,4)}
< org.jboss.netty.channel.group {resolution:=optional,
version=[3.7,4)}
< org.jboss.netty.channel.socket.nio {resolution:=optional,
version=[3.7,4)}
187d179
< sun.security.krb5 {resolution:=optional}
{noformat}
As you can see the zookeeper packages are now imported (because they are not
provided within the bundle), and some other packages that are only used by
zookeeper are no longer imported. If zookeeper with its org.slf4j.slf4j-log4j12
dependency was the cause for {{org.slf4j.impl}} to be imported, then we would
expect it to disappear when zookeeper is no longer embedded.
This is not the case, ergo zookeeper is not the root cause you're looking for.
As I outlined before, the root cause is Solr itself.
> Note that IIUC embedding dependencies of oak-solr-core is one of the points
> of oak-solr-osgi.
I don't think embedding a logging binding was ever the goal of oak-solr-osgi.
If you are interested in the original reasoning why this bundle was created,
the discussion https://markmail.org/thread/5xsyx5l4c6euqtt2 may be interesting.
> 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)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17100190#comment-17100190
]
Manfred Baedke commented on OAK-9024:
-
[~jsedding], I think we understand the root cause, see
https://issues.apache.org/jira/browse/OAK-9024?focusedCommentId=17089747&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17089747
> 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)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098861#comment-17098861
]
Julian Sedding commented on OAK-9024:
-
[~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)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17096922#comment-17096922
]
Manfred Baedke commented on OAK-9024:
-
Thx a lot, [~jsedding], that's a good tool to know. But don't you think that in
this case it's simpler and less risky just to embed slf4j-log4j12 as the patch
does?
> 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)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17096470#comment-17096470
]
Julian Reschke commented on OAK-9024:
-
https://github.com/apache/lucene-solr/blob/branch_6_6/solr/core/src/java/org/apache/solr/servlet/StartupLoggingUtils.java#L30
https://github.com/apache/lucene-solr/blob/branch_6_6/solr/core/src/java/org/apache/solr/logging/LogWatcher.java#L26
> 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)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17096360#comment-17096360
]
Julian Sedding commented on OAK-9024:
-
bndtools may have the answer, in particular the [xref
command|https://bnd.bndtools.org/commands/xref.html]
The following is an excerpt from its output, indicating which classes use
(i.e. import on a java level) classes from {{org.slf4j.impl}}.
{noformat}
$ bnd xref -cf target/oak-solr-osgi-1.27-SNAPSHOT.jar
...
org.slf4j.impl.StaticLoggerBinder < org.apache.solr.logging.LogWatcher
org.apache.solr.servlet.StartupLoggingUtils
...
{noformat}
Removing these two classes from the {{Embed-Dependency}} instruction should
remove the import for {{org.slf4j.impl}}. However, it woudl still be required
to analyze where the Oak code (transitively) depends on these classes and
examine if it can be safely used without them. If removing these classes is not
an option, it may still be safe to exclude the import for {{org.slf4j.impl}}
explicitly, iff no code path is used, where the {{StaticLoggerBinder}} is used.
If it _is_ used, however, then it we really need {{StaticLoggerBinder}} on the
class path (or provide an upstream fix for Solr).
> 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)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17095874#comment-17095874
]
Manfred Baedke commented on OAK-9024:
-
Embedding oak-solr-core transitively doesn't work. The dependency analyzer only
checks the byte code, which is not sufficient. So I'm going to commit the
applied patch.
> 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)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089841#comment-17089841
]
Manfred Baedke commented on OAK-9024:
-
That being said, I think the correct solution would be embedding oak-solr-core
transitively. If we don't do that, we always have to keep track of the versions
of embedded artifacts manually. Has anyone an idea about the build error
mentioned in my last post?
cc [~reschke][~cziegeler][~thomasm]
> 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)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089747#comment-17089747
]
Manfred Baedke commented on OAK-9024:
-
oak-solr-osgi embeds org.apache.zookeeper.zookeeper, because it's a runtime
dependency of org.apache.solrsolr-core.
zookeeper has a compile dependency to org.slf4j.slf4j-log4j12 (for some -
certainly not good - reason).
That's why we see that import. First I tried to embed the runtime dependencies
transitively, which simply breaks the maven build. I don't understand why, the
exception is
{code}
[ERROR] Manifest org.apache.jackrabbit:oak-solr-osgi:bundle:1.27-SNAPSHOT : Got
unexpected exception while
analyzing:org.apache.felix.scrplugin.SCRDescriptorException: Unable to load
compiled class: com.google.common.collect.Constraints$NotNullConstraint
at
org.apache.felix.scrplugin.helper.ClassScanner.scanSources(ClassScanner.java:156)
at
org.apache.felix.scrplugin.SCRDescriptorGenerator.execute(SCRDescriptorGenerator.java:146)
at
org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin.analyzeJar(SCRDescriptorBndPlugin.java:179)
at aQute.bnd.osgi.Analyzer.doPlugins(Analyzer.java:879)
at aQute.bnd.osgi.Analyzer.analyze(Analyzer.java:239)
at aQute.bnd.osgi.Builder.analyze(Builder.java:408)
at aQute.bnd.osgi.Analyzer.calcManifest(Analyzer.java:909)
at aQute.bnd.osgi.Builder.build(Builder.java:118)
at
org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer(ManifestPlugin.java:308)
at
org.apache.felix.bundleplugin.ManifestPlugin.execute(ManifestPlugin.java:111)
at
org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:364)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:954)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: java.lang.IllegalAccessError: class
com.google.common.collect.Constraints$NotNullConstraint cannot access its
superinterface com.google.common.collect.Constraint
(com.google.common.collect.Constraints$NotNullConstraint is in unnamed module
of loader java.net.URLClassLoader @368e9d5c;
com.google.common.collect.Constraint is in unnamed module of loader
org.codehaus.plexus.classworlds.realm.ClassRealm @53c68ce)
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
at
java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
at
java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:550)
at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:458)
at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:452)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:451)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:588)
at java.base/java.lang.Cl
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089716#comment-17089716
]
Julian Reschke commented on OAK-9024:
-
Opened a separate ticket for oak-search-mt
(https://issues.apache.org/jira/browse/OAK-9038). Stumbled upon slf4j-api being
declared as "provided" dependency. Does anybody get what that is being used?
> 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
>Priority: Minor
> Fix For: 1.28.0
>
>
> From the manifest:
> {{org.slf4j.impl;version="[1.6,2)"}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089475#comment-17089475
]
Carsten Ziegeler commented on OAK-9024:
---
[~reschke] I assume you are embedding other jars. So one possible way is to
only embed a single jar and see whether the import is still there. If yes, you
found the artifact that is generating it, if not you continue with the next
embedded jar. Once you know the artifact, you can check out their source code
and see where this is used. It might that this is coming from a class that is
not really used by oak at runtime, in that case removing the import would be a
solution
> 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
>Priority: Minor
> Fix For: 1.28.0
>
>
> From the manifest:
> {{org.slf4j.impl;version="[1.6,2)"}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089414#comment-17089414
]
Julian Reschke commented on OAK-9024:
-
[~cziegeler] - any ideas about how to debug this?
> 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
>Priority: Minor
> Fix For: 1.28.0
>
>
> From the manifest:
> {{org.slf4j.impl;version="[1.6,2)"}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089403#comment-17089403
]
Thomas Mueller commented on OAK-9024:
-
I checked if oak-core or jackrabbit or oak-blob-plugins imports slf4j.impl,
they don't. But I don't know what else to investigate, so I give up. More
insights and patches are welcome!
> 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
>Priority: Minor
> Fix For: 1.28.0
>
>
> From the manifest:
> {{org.slf4j.impl;version="[1.6,2)"}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089400#comment-17089400
]
Julian Reschke commented on OAK-9024:
-
That's exactly where I ended up myself :-). Maybe we need an OSGi expert here?
> 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
>Priority: Minor
> Fix For: 1.28.0
>
>
> From the manifest:
> {{org.slf4j.impl;version="[1.6,2)"}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089374#comment-17089374
]
Thomas Mueller commented on OAK-9024:
-
I have to admit I don't have much insight in how this is supposed to work.
Looking at the pom file oak-solr-osgi/pom.xml (and that project only has a pom
file), I don't see slf4j.impl. I see:
{noformat}
org.apache.solr
solr-core
${solr.version}
org.slf4j
slf4j-jdk14
org.apache.hadoop
hadoop-annotations
commons-fileupload
commons-fileupload
runtime
{noformat}
That's it.
The dependencies are:
{noformat}
mvn dependency:tree
[INFO] --- maven-dependency-plugin:2.10:tree (default-cli) @ oak-solr-osgi ---
[INFO] org.apache.jackrabbit:oak-solr-osgi:bundle:1.27-SNAPSHOT
[INFO] +- org.osgi:org.osgi.core:jar:4.2.0:provided
[INFO] +- org.osgi:org.osgi.compendium:jar:4.2.0:provided
[INFO] +- org.apache.jackrabbit:oak-core:jar:1.27-SNAPSHOT:provided
[INFO] | +- org.osgi:org.osgi.service.component.annotations:jar:1.3.0:provided
[INFO] | +- org.osgi:org.osgi.service.metatype.annotations:jar:1.3.0:provided
[INFO] | +- org.apache.jackrabbit:oak-jackrabbit-api:jar:1.27-SNAPSHOT:runtime
[INFO] | +- org.apache.jackrabbit:oak-api:jar:1.27-SNAPSHOT:runtime
[INFO] | +- org.apache.jackrabbit:oak-core-spi:jar:1.27-SNAPSHOT:runtime
[INFO] | +- org.apache.jackrabbit:oak-query-spi:jar:1.27-SNAPSHOT:runtime
[INFO] | +- org.apache.jackrabbit:oak-security-spi:jar:1.27-SNAPSHOT:provided
[INFO] | +- org.apache.jackrabbit:oak-commons:jar:1.27-SNAPSHOT:runtime
[INFO] | +- org.apache.jackrabbit:oak-blob-plugins:jar:1.27-SNAPSHOT:provided
[INFO] | | +- org.apache.jackrabbit:jackrabbit-data:jar:2.20.0:provided
[INFO] | | +- org.apache.jackrabbit:oak-blob:jar:1.27-SNAPSHOT:provided
[INFO] | | \- org.osgi:org.osgi.annotation:jar:6.0.0:provided
[INFO] | +- org.apache.jackrabbit:oak-store-spi:jar:1.27-SNAPSHOT:runtime
[INFO] | +- com.google.guava:guava:jar:15.0:runtime
[INFO] | +- commons-io:commons-io:jar:2.6:runtime
[INFO] | +- javax.jcr:jcr:jar:2.0:runtime
[INFO] | +- org.apache.jackrabbit:jackrabbit-jcr-commons:jar:2.20.0:runtime
[INFO] | \- org.slf4j:slf4j-api:jar:1.7.30:runtime
[INFO] +- org.apache.jackrabbit:oak-solr-core:jar:1.27-SNAPSHOT:runtime
[INFO] +- org.apache.jackrabbit:oak-search:jar:1.27-SNAPSHOT:runtime
[INFO] | \- org.apache.tika:tika-core:jar:1.24:runtime
[INFO] +- org.apache.solr:solr-core:jar:6.6.6:runtime
[INFO] | +- org.apache.lucene:lucene-analyzers-kuromoji:jar:6.6.6:runtime
[INFO] | +- org.apache.lucene:lucene-analyzers-phonetic:jar:6.6.6:runtime
[INFO] | +- org.apache.lucene:lucene-backward-codecs:jar:6.6.6:runtime
[INFO] | +- org.apache.lucene:lucene-classification:jar:6.6.6:runtime
[INFO] | +- org.apache.lucene:lucene-codecs:jar:6.6.6:runtime
[INFO] | +- org.apache.lucene:lucene-expressions:jar:6.6.6:runtime
[INFO] | +- org.apache.lucene:lucene-memory:jar:6.6.6:runtime
[INFO] | +- org.apache.lucene:lucene-spatial-extras:jar:6.6.6:runtime
[INFO] | +- com.fasterxml.jackson.core:jackson-annotations:jar:2.10.3:runtime
[INFO] | +- com.fasterxml.jackson.core:jackson-databind:jar:2.10.3:runtime
[INFO] | +- com.github.ben-manes.caffeine:caffeine:jar:2.4.0:runtime
[INFO] | +- com.google.protobuf:protobuf-java:jar:3.1.0:runtime
[INFO] | +- com.tdunning:t-digest:jar:3.1:runtime
[INFO] | +- commons-codec:commons-codec:jar:1.14:runtime
[INFO] | +- commons-collections:commons-collections:jar:3.2.2:runtime
[INFO] | +- commons-configuration:commons-configuration:jar:1.6:runtime
[INFO] | +- dom4j:dom4j:jar:1.6.1:runtime
[INFO] | +- info.ganglia.gmetric4j:gmetric4j:jar:1.0.7:runtime
[INFO] | +- io.dropwizard.metrics:metrics-core:jar:3.2.3:runtime
[INFO] | +- io.dropwizard.metrics:metrics-ganglia:jar:3.2.2:runtime
[INFO] | +- io.dropwizard.metrics:metrics-graphite:jar:3.2.2:runtime
[INFO] | +- io.dropwizard.metrics:metrics-jetty9:jar:3.2.2:runtime
[INFO] | +- io.dropwizard.metrics:metrics-jvm:jar:3.2.2:runtime
[INFO] | +- javax.servlet:javax.servlet-api:jar:3.1.0:runtime
[INFO] | +- joda-time:joda-time:jar:2.2:runtime
[INFO] | +- log4j:log4j:jar:1.2.17:runtime
[INFO] | +- net.hydromatic:eigenbase-properties:jar:1.1.5:runtime
[INFO] | +- org.antlr:antlr4-runtime:jar:4.5.1-1:runtime
[INFO] | +- org.apache.calcite:calcite-core:jar:1.11.0:runtime
[INFO] | +- org.apache.calcite:calcite-linq4j:jar:1.11.0:runtime
[INFO] | +- org.apache.calcite.avatica:avatica-core:jar:1.9.0:runtime
[INFO] | +- org.apache.curator:curator-client:jar:2.8.0:runtime
[INFO] | +- org.apache.curator:curator-framework:jar:2.8.0:runtime
[INFO] |
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087668#comment-17087668
]
Julian Reschke commented on OAK-9024:
-
`mvn clean bundle:manifest -DniceManifest=true ; fgrep slf4j.impl
*/*/classes/*/MANIFEST.MF`
produces
{noformat}
oak-search-mt/target/classes/META-INF/MANIFEST.MF:
org.slf4j.impl;version="[1.7,2)",
oak-solr-osgi/target/classes/META-INF/MANIFEST.MF:
org.slf4j.impl;version="[1.6,2)", {noformat}
so oak-search-mt has a similar issue.
> 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
>Priority: Minor
> Fix For: 1.28.0
>
>
> From the manifest:
> {{org.slf4j.impl;version="[1.6,2)"}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
