Dynamic plugins are forced to use sfl4j-simple binding

mwoodland commented 5 years ago

I have a combination of static and dynamic plugins. Prior to upgrading to dotCMS 5.0.3 I was using the dotCMS configuration plugin to install the logback libraries and configuration files to use for slf4j binding. This configuration was working and being used for both static and dynamic plugins.

After upgrading to 5.0.3 the logback configuration is now only being used for static plugins and is not working for dynamic plugins. This appears to be because slf4j-simple has been added to the felix/bundle directory in the dotCMS installation and so the slf4j-simple binding is being used instead of the logback binding. (Note slf4j-simple was added in this commit https://github.com/dotCMS/core/commit/7d987bf2d810813e317e62e888ab0d240210a91e but it's not obvious to me why slf4j-simple was required for moving tika from a tomcat library to an OSGI plugin.

Expected Behavior

I'd expect to be able to use the slf4j binding of my choosing for both static and dynamic plugins.

Current Behavior

I can only use the slf4j binding of my choosing for static plugins, dynamic plugins are forced to use the slf4j-simple binding.

Possible Solution

Don't provide a binding as part of the base dotCMS installation. From slf4j 1.6.0 onward if no slf4j binding is found on the class path, then slf4j will default to a no-operation implementation.

I'd like to be able to pick my own binding so I can configure the logging how I like rather than being forced to stick with one particular logging framework.

Known Workarounds

Delete the slf4j-simple jar from the felix/bundle directory as a manual step as part of the installation of dotCMS.

Steps to Reproduce (for bugs)

Use the dotCMS configuration plugin to add logback-core and logback-classic jars to the installation (by putting them in the plugins/com.dotcms.config/lib/ folder)
Configure a logback.xml file with some custom logging configuration and use the dotCMS configuration plugin to install this (put it in the plugins/com.dotcms.config/ROOT/dotserver/tomcat-8.5.32/webapps/ROOT/WEB-INF/classes/ folder).
Use both a static and a dynamic plugin that use slf4j logging.

The static plugin will be logged according to the logback configuration, but the dynamic plugin will be logged to catalina.out and the logback configuration ignored because slf4j will be using the slf4j-simple binding.

Context

I've had to add a step to my dotCMS installation to delete the slf4j-simple jar.

Your Environment

dotCMS version used: 5.0.3
Browser Name and version: N/A
Operating System and version: CentOS 7.5.1804
Application Server and version: tomcat-8.5.32
Java Brand and version: jdk-8u152
Database and version: mysql57-community-release

mwoodland commented 5 years ago

When I tried putting the logback-core and logback-classic jars in the felix/bundle folder I could see that felix was correctly loading these bundles, but my dynamic plugins were still using the slf4j-classic jars and so my logback configuration still didn't work.

jgambarios commented 5 years ago

After removing locally the slf4j-simple dependency I have dependencies errors starting dotCMS:

DEBUG: DYNAMIC WIRE: [com.dotcms.tika [1](R 1.0)] osgi.wiring.package; (osgi.wiring.package=*) -> [org.apache.felix.framework [0](R 0)]
ERROR: Bundle jcl.over.slf4j [2] Error starting file:/Users/jonathan/Projects/dotCMS/repository/git/tomcat8/webapps/ROOT/WEB-INF/felix/bundle/jcl-over-slf4j-1.7.25.jar (org.osgi.framework.BundleException: Unable to resolve jcl.over.slf4j [2](R 2.0): missing requirement [jcl.over.slf4j [2](R 2.0)] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j.spi)(version>=1.7.25)) [caused by: Unable to resolve slf4j.api [8](R 8.0): missing requirement [slf4j.api [8](R 8.0)] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j.impl)(version>=1.6.0))] Unresolved requirements: [[jcl.over.slf4j [2](R 2.0)] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j.spi)(version>=1.7.25))])
org.osgi.framework.BundleException: Unable to resolve jcl.over.slf4j [2](R 2.0): missing requirement [jcl.over.slf4j [2](R 2.0)] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j.spi)(version>=1.7.25)) [caused by: Unable to resolve slf4j.api [8](R 8.0): missing requirement [slf4j.api [8](R 8.0)] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j.impl)(version>=1.6.0))] Unresolved requirements: [[jcl.over.slf4j [2](R 2.0)] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j.spi)(version>=1.7.25))]
    at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4149)
    at org.apache.felix.framework.Felix.startBundle(Felix.java:2119)
    at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373)
    at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
    at java.lang.Thread.run(Thread.java:748)

mwoodland commented 5 years ago

I'm not sure why you'd be getting that error. The slf4j-api library should be providing that package (org.slf4j.spi) as far as I can tell. See the MANIFEST.MF from slf4j-api below:

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: ceki
Build-Jdk: 1.7.0_17
Bundle-Description: The slf4j API
Bundle-Version: 1.7.25
Implementation-Version: 1.7.25
X-Compile-Source-JDK: 1.5
X-Compile-Target-JDK: 1.5
Implementation-Title: slf4j-api
Bundle-ManifestVersion: 2
Bundle-SymbolicName: slf4j.api
Bundle-Name: slf4j-api
Bundle-Vendor: SLF4J.ORG
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Export-Package: org.slf4j;version=1.7.25, org.slf4j.spi;version=1.7.25
 , org.slf4j.helpers;version=1.7.25, org.slf4j.event;version=1.7.25
Import-Package: org.slf4j.impl;version=1.6.0

jgambarios commented 5 years ago

I guess it is because of

missing requirement [slf4j.api [8](R 8.0)] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j.impl)(version>=1.6.0))]

which is provided by the sfl4j-simple

jgambarios commented 5 years ago

@mwoodland I tried your new changes but I think we have to take another route, felix and tika start without problems but org.apache.pdfbox is complaining about java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory when we try to parse a pdf file, that package is part of the jcl-over-slf4j jar and with that error we are not able to parse properly pdf files.

Have you tried to ignore the slf4j-simple in your OSGI plugin?, if I'm right you can do something like 'Import-Package': '!dont.import.my.package.*,*;version=0'

mwoodland commented 5 years ago

I don't think that'll work because I do want the package I just want it from a different bundle that exports that package. I'm not sure if it's possible to specify which bundle to get the package from.

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had activity within the past 90 days. It will be closed in 30 days no further activity occurs. Thank you.

dotCMS / core