You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by "Daan Hoogland (JIRA)" <ji...@apache.org> on 2017/09/25 07:35:02 UTC

[jira] [Comment Edited] (LOG4J2-1971) ClassCastException: org.eclipse.osgi.internal.loader.SystemBundleLoader$1 cannot be cast to java.lang.ClassLoader

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

Daan Hoogland edited comment on LOG4J2-1971 at 9/25/17 7:34 AM:
----------------------------------------------------------------

People, I am getting this outside OSGi context. I try to up the log4j version in Apache CloudStack and got 
java.util.ServiceConfigurationError: org.apache.logging.log4j.spi.Provider: Provider org.apache.logging.log4j.core.impl.Log4jProvider not a subtype
in a test case that 'seems' to only load a logger in it's target and do nothing else with logging
I try to change the line in
https://github.com/apache/cloudstack/blob/master/utils/src/main/java/com/cloud/utils/ssh/SshHelper.java#L42
t use the LogManager from log4j2 instead of Logger.getLogger() and it throws the exception shown above.
api-2.9.1. is used for this experiment. Any pointers that could help me solve the problem, please?

The target is being loaded as a PowerMock.spy(), btw. That might throw some extra weight in the mix...


was (Author: dahn):
People, I am getting this outside OSGi context. I try to up the log4j version in Apache CloudStack and got 
java.util.ServiceConfigurationError: org.apache.logging.log4j.spi.Provider: Provider org.apache.logging.log4j.core.impl.Log4jProvider not a subtype
in a test case that 'seems' to only load a logger in it's target and do nothing else with logging
I try to change the line in
https://github.com/apache/cloudstack/blob/master/utils/src/main/java/com/cloud/utils/ssh/SshHelper.java#L42
t use the LogManager from log4j2 instead of Logger.getLogger() and it throws the exception shown above.
api-2.9.1. is used for this experiment. Any pointers that could help me solve the problem, please?

> ClassCastException: org.eclipse.osgi.internal.loader.SystemBundleLoader$1 cannot be cast to java.lang.ClassLoader
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: LOG4J2-1971
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1971
>             Project: Log4j 2
>          Issue Type: Bug
>    Affects Versions: 2.8
>            Reporter: liwenxian2017
>             Fix For: 2.9.0
>
>
> When I migrated log4j from log4j 1.2.17 to log4j 2.8, There is an Exception like this:
> java.lang.ClassCastException: org.eclipse.osgi.internal.loader.SystemBundleLoader$1 cannot be cast to java.lang.ClassLoaderat org.eclipse.osgi.internal.resolver.BundleDescriptionImpl$DescriptionWiring.getClassLoader(BundleDescriptionImpl.java:1229) ~[org.eclipse.osgi.jar:?]at org.apache.logging.log4j.core.osgi.Activator.scanBundleForPlugins(Activator.java:70) ~[log4j-core.jar:2.8]at org.apache.logging.log4j.core.osgi.Activator.bundleChanged(Activator.java:91) ~[log4j-core.jar:2.8]at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:847) ~[org.eclipse.osgi.jar:?]at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) ~[org.eclipse.osgi.jar:?]at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) ~[org.eclipse.osgi.jar:?]at org.eclipse.osgi.framework.internal.core.Framework.publishBundleEventPrivileged(Framework.java:1568) ~[org.eclipse.osgi.jar:?]at org.eclipse.osgi.framework.internal.core.Framework.publishBundleEvent(Framework.java:1504) ~[org.eclipse.osgi.jar:?]at org.eclipse.osgi.framework.internal.core.Framework.publishBundleEvent(Framework.java:1499) ~[org.eclipse.osgi.jar:?]at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:247) ~[org.eclipse.osgi.jar:?]at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438) ~[org.eclipse.osgi.jar:?]at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1) ~[org.eclipse.osgi.jar:?]at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) ~[org.eclipse.osgi.jar:?]at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) ~[org.eclipse.osgi.jar:?]
> I checked Activator.java in log4j-core:
> ...
> 86 @Override
> 87 public void bundleChanged(final BundleEvent event) {
> 88  switch (event.getType()) {
> 89   // FIXME: STARTING instead of STARTED?
> 90   case BundleEvent.STARTED:
> 91    scanBundleForPlugins(event.getBundle());
> 92   break;
> in line 91, it called scanBundleForPlugins for every bundles. But in line 60-61, it does not scan system bundle for plugins
> 57 private static void scanInstalledBundlesForPlugins(final BundleContext context) {
> 58    final Bundle[] bundles = context.getBundles();
> 59    for (final Bundle bundle : bundles) {
> 60       // LOG4J2-920: don't scan system bundle for plugins
> 61       if (bundle.getState() == Bundle.ACTIVE && bundle.getBundleId() != 0) {
> 62          // TODO: bundle state can change during this
> 63          scanBundleForPlugins(bundle);
> And org.eclipse.osgi_3.8.1 's bundle ID is just 0. So it skipped bundle org.eclipse.osgi in line 61-63. but it does not in line 91
> If I changed line 91 to:
>   if (event.getBundle().getState() == Bundle.ACTIVE && event.getBundle().getBundleId() != 0) {
>     scanBundleForPlugins(event.getBundle());
>   }
> The exception goes away.
> So is this a bug? Or this is NOT a bug and there is a workaround for this Exception? Thanks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)