-
Notifications
You must be signed in to change notification settings - Fork 835
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configure commons-logging to log using java.util.logging #7346
Conversation
It was observed that maven classpath display failed. The stack trace: [exec] SEVERE [org.openide.util.RequestProcessor]: Error in RequestProcessor org.netbeans.modules.maven.repository.ui.ArtifactMultiViewFactory$1 [exec] java.lang.ClassNotFoundException: org.slf4j.MarkerFactory cannot be found by org.apache.commons.logging_1.3.1 [exec] at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501) [exec] at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421) [exec] at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412) [exec] at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) [exec] at org.netbeans.modules.netbinox.NetbinoxLoader.loadClass(NetbinoxLoader.java:55) [exec] at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526) [exec] Caused: java.lang.NoClassDefFoundError: org/slf4j/MarkerFactory [exec] at org.apache.commons.logging.impl.Slf4jLogFactory.<clinit>(Slf4jLogFactory.java:255) [exec] at java.base/java.lang.Class.forName0(Native Method) [exec] at java.base/java.lang.Class.forName(Class.java:421) [exec] at java.base/java.lang.Class.forName(Class.java:412) [exec] at org.apache.commons.logging.LogFactory.createFactory(LogFactory.java:419) [exec] at org.apache.commons.logging.LogFactory.lambda$newFactory$3(LogFactory.java:1432) [exec] at java.base/java.security.AccessController.doPrivileged(AccessController.java:319) [exec] at org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:1431) [exec] at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:934) [exec] at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:987) [exec] at org.apache.http.conn.ssl.AbstractVerifier.<init>(AbstractVerifier.java:61) [exec] at org.apache.http.conn.ssl.AllowAllHostnameVerifier.<init>(AllowAllHostnameVerifier.java:44) [exec] at org.apache.http.conn.ssl.AllowAllHostnameVerifier.<clinit>(AllowAllHostnameVerifier.java:46) [exec] at org.apache.http.conn.ssl.SSLConnectionSocketFactory.<clinit>(SSLConnectionSocketFactory.java:151) [exec] at org.eclipse.aether.transport.http.GlobalState.newConnectionManager(GlobalState.java:169) [exec] at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1708) [exec] at org.eclipse.aether.transport.http.GlobalState.getConnectionManager(GlobalState.java:145) [exec] at org.eclipse.aether.transport.http.LocalState.<init>(LocalState.java:62) [exec] at org.eclipse.aether.transport.http.HttpTransporter.<init>(HttpTransporter.java:197) [exec] at org.eclipse.aether.transport.http.HttpTransporterFactory.newInstance(HttpTransporterFactory.java:95) [exec] at org.eclipse.aether.internal.impl.DefaultTransporterProvider.newTransporter(DefaultTransporterProvider.java: indicates, that commons-logging tries to load slf4j to handle logging, but fails. Running with "-J-Dorg.apache.commons.logging.diagnostics.dest=STDERR" supports that conclusion: [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] [ENV] Extension directories (java.ext.dir): null [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] [ENV] Application classpath (java.class.path): /home/matthias/src/netbeans/nbbuild/netbeans/platform/lib/boot.jar:/home/matthias/src/netbeans/nbbuild/netbeans/platform/lib/org-openide-modules.jar:/home/matthias/src/netbeans/nbbuild/netbeans/platform/lib/org-openide-util.jar:/home/matthias/src/netbeans/nbbuild/netbeans/platform/lib/org-openide-util-lookup.jar:/home/matthias/src/netbeans/nbbuild/netbeans/platform/lib/org-openide-util-ui.jar [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] [ENV] Class org.apache.commons.logging.LogFactory was loaded via class loader org.netbeans.modules.netbinox.NetbinoxLoader@244303269 [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] [ENV] Ancestry of class loader which loaded org.apache.commons.logging.LogFactory is org.netbeans.modules.netbinox.NetbinoxLoader@244303269 == 'NetbinoxLoader delegating to org.apache.commons.logging_1.3.1' [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] [ENV] Ancestry of class loader which loaded org.apache.commons.logging.LogFactory is ClassLoader tree:org.netbeans.modules.netbinox.NetbinoxLoader@244303269 --> jdk.internal.loader.ClassLoaders$PlatformClassLoader@1922830567 --> BOOT [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] BOOTSTRAP COMPLETED [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] [LOOKUP] LogFactory implementation requested for the first time for context class loader org.codehaus.plexus.classworlds.realm.ClassRealm@1303991949 [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] [LOOKUP] org.codehaus.plexus.classworlds.realm.ClassRealm@1303991949 == 'ClassRealm[project>org.knowm.xchart:xchart:3.8.7, parent: ClassRealm[maven.api, parent: null]]' [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] [LOOKUP] ClassLoader tree:org.codehaus.plexus.classworlds.realm.ClassRealm@1303991949 --> BOOT [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] [LOOKUP] No properties file of name 'commons-logging.properties' found. [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] [LOOKUP] Looking for system property [org.apache.commons.logging.LogFactory] to define the LogFactory subclass to use... [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] [LOOKUP] No system property [org.apache.commons.logging.LogFactory] defined. [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] [LOOKUP] Using ServiceLoader to define the LogFactory subclass to use... [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] [LOOKUP] No properties file available to determine LogFactory subclass from.. [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] Checking if class 'org.apache.logging.log4j.Logger' is available in class loader org.netbeans.modules.netbinox.NetbinoxLoader@244303269 [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] Failed to load class 'org.apache.logging.log4j.Logger' from class loader org.netbeans.modules.netbinox.NetbinoxLoader@244303269: org.apache.logging.log4j.Logger [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] Checking if class 'org.slf4j.Logger' is available in class loader org.netbeans.modules.netbinox.NetbinoxLoader@244303269 [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] [LOOKUP] SLF4J detected. Loading the SLF4J LogFactory implementation 'org.apache.commons.logging.impl.Slf4jLogFactory'. [LogFactory from org.netbeans.modules.netbinox.NetbinoxLoader@244303269] Unable to load factory class via class loader org.codehaus.plexus.classworlds.realm.ClassRealm@1303991949 - trying the class loader associated with this LogFactory. SEVERE [org.openide.util.RequestProcessor]: Error in RequestProcessor org.netbeans.modules.maven.repository.ui.ArtifactMultiViewFactory$1
To reproduce this, I opened the project supplied from #7345, opened the dependency node and invoked "View Artifact Details" on the xchart dependency and choose Classpath. The classpath was not shown to me and generating the dependency graph then resulted in the stacktrace. While testing my changes I temporary removed my local maven repository. |
@matthiasblaesing I am not really an OSGI specialist since I always tried to avoid the extra overhead of it wherever I could but I know that logging libs usually try to find the factory via the standard service loader mechanism first, then check the class loader if that fails (at this point it usually prints a warning directly to System.out). Does this mean it didn't work using the regular mechanisms so you went with the bundle activator route? |
@mbien my understanding is, that commons-logging will detect Log4j and SLF4J on the classpath. If it finds them, it will use one of these. The problem is, that the class loader commons-logging uses is the thread context class loader, which can see all resources of all modules of NetBeans. Later Instantiation will fail because there is not dependency from commons-logging to SLF4J established. The detection can be observed here:
The load failure is the stack trace. We could also move SLF4J to the platform cluster, change the Manifest of commons-logging to depend on it and it would work, but from my POV it is nuts to log commons-logging -> SLF4J -> JUL, if you can go directly to commons-logging -> JUL. |
this got merged to master by accident |
Ah sorry! I branched from delivery and I seem to have messed this up when opening the PR. Damn. @ebarboni @mbien I can prepare a new PR with the same commit against delivery. My expectation would be, that git can handle the commit handle in both branches, once delivery is merged into master. What do you think? |
@matthiasblaesing I chatted with @neilcsmith-net and @ebarboni on slack and I believe eric wanted to fix this manually by cherry picking the commit to delivery (on monday). Git indeed should be able to figure this out on the next sync. But I suppose a second PR targeting delivery would do the exact same. If you label it with "Release process" it will also skip the release notes. |
@mbien yes, as the parent commit is on delivery this should amount to same thing. Cherry picking would still be via PR anyway to ensure CI passes before merging. |
It was observed that maven classpath display failed. The stack trace:
indicates, that commons-logging tries to load slf4j to handle logging, but fails. Running with
"-J-Dorg.apache.commons.logging.diagnostics.dest=STDERR" supports that conclusion: