Matt, I don’t think that makes a difference when running in OSGi. The problem is that core is calling API and asking it to load a core class. Unless it has access to the class it can’t do it. In OSGi it will only have access if log4j-core exposes it.
Ralph > On Oct 4, 2018, at 9:01 AM, Matt Sicker <[email protected]> wrote: > > LoaderUtil is using the thread context class loader by default. If it's not > set right, you can use of the methods there to specify the correct > ClassLoader, or you can even push and pop TCCLs essentially. > > On Wed, 3 Oct 2018 at 16:46, Ralph Goers <[email protected]> wrote: > >> Personally, I would rather duplicate the code, as much as it pains me to >> do that. >> >> Ralph >> >>> On Oct 3, 2018, at 1:37 PM, Rob Gansevles <[email protected]> wrote: >>> >>> This patch is not effective in case of the BasicContextSelector because >>> package org.apache.logging.log4j.core.selector was not included in the >>> imports. >>> Only org.apache.logging.log4j.core.osgi, >> org.apache.logging.log4j.core.util >>> and org.apache.logging.log4j.core.async are includes as optional imports >> in >>> log4j-api. >>> >>> If org.apache.logging.log4j.core.selector was added as well, >>> BasicContextSelector could be used in an OSGI application. >>> >>> >>> I agree that it is weird that log4j-api depends on log4j-core. >>> The only reason this is needed because the utility methods in log4j-api >> are >>> used to load the classes. >>> I did a small experiment where I copied >>> LoaderUtil.newCheckedInstanceOfProperty() from log4j-api to a utility >> class >>> in log4j-core. >>> This also fixes the problem because then dynamic classes are loaded from >>> core and can be found (since they are defined in core). >>> >>> It unfortunately introduces a lot of code duplication (5 methods from >>> LoaderUtil). >>> >>> What do you think, would this be a good idea instead and remove all >>> dependencies from log4j-api to log4j-core? >>> >>> Rob >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Sep 28, 2018 at 7:38 PM Ralph Goers <[email protected]> >>> wrote: >>> >>>> Despite what I said below, it seems that the patch for LOG4J2-920 was >>>> applied over 2 years ago so this should not be happening with 2.11.1. >>>> >>>> Ralph >>>> >>>>> On Sep 28, 2018, at 10:34 AM, Ralph Goers <[email protected]> >>>> wrote: >>>>> >>>>> It sounds related to LOG4J2-920 but the solution provided there has to >>>> be incorrect. There is no way the Log4j API should be declaring any >>>> requirements on Log4j Core stuff, especially since the Log4j API doesn’t >>>> have a clue what a ContextSelector is. That is only use by the >>>> Log4jContextFactory. I suspect the problem is that LoaderUtil resides in >>>> log4j-api and since it is actually doing the loading it is causing the >>>> problem. That means we are either doing the loading wrong or there is >>>> something broken in OSGi. >>>>> >>>>> Ralph >>>>> >>>>>> On Sep 28, 2018, at 10:20 AM, Rob Gansevles <[email protected]> >>>> wrote: >>>>>> >>>>>> Yes, that makes sense, but it seems they are still loaded by the >>>> log4j-api. >>>>>> I guess this is the reason there are a few optional import-package >>>>>> declarations in the manifest-generation in the pom for log4j-api: >>>>>> >>>>>> <plugin> >>>>>> <groupId>org.apache.felix</groupId> >>>>>> <artifactId>maven-bundle-plugin</artifactId> >>>>>> <configuration> >>>>>> <instructions> >>>>>> <Export-Package>org.apache.logging.log4j.*</Export-Package> >>>>>> <Import-Package> >>>>>> sun.reflect;resolution:=optional, >>>>>> org.apache.logging.log4j.core.osgi;resolution:=optional, >>>>>> org.apache.logging.log4j.core.util;resolution:=optional, >>>>>> org.apache.logging.log4j.core.async;resolution:=optional, >>>>>> * >>>>>> </Import-Package> >>>>>> >>>>>> >>>> >> <Bundle-Activator>org.apache.logging.log4j.util.Activator</Bundle-Activator> >>>>>> <_fixupmessages>"Classes found in the wrong >>>>>> directory";is:=warning</_fixupmessages> >>>>>> </instructions> >>>>>> </configuration> >>>>>> </plugin> >>>>>> >>>>>> I get the error below when I use the BasicContextSelector, and when I >>>> add >>>>>> org.apache.logging.log4j.core.selector to the imports in the manifest >> it >>>>>> works. >>>>>> >>>>>> Maybe it is the same issue as discussed in LOG4J2-920 but then >>>>>> for BundleContextSelector and should a similar patch being applied. >>>>>> What do you think? >>>>>> >>>>>> ERROR StatusLogger Unable to create custom ContextSelector. Falling >>>> back to >>>>>> default. >>>>>> java.lang.ClassNotFoundException: >>>>>> org.apache.logging.log4j.core.selector.BasicContextSelector cannot be >>>> found >>>>>> by org.apache.logging.log4j.api_2.11.2.SNAPSHOT >>>>>> at >>>>>> >>>> >> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:508) >>>>>> at >>>>>> >>>> >> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419) >>>>>> at >>>>>> >>>> >> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411) >>>>>> at >>>>>> >>>> >> org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150) >>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) >>>>>> at java.lang.Class.forName0(Native Method) >>>>>> at java.lang.Class.forName(Class.java:264) >>>>>> at >>>> org.apache.logging.log4j.util.LoaderUtil.loadClass(LoaderUtil.java:168) >>>>>> at >>>>>> >>>> >> org.apache.logging.log4j.util.LoaderUtil.newInstanceOf(LoaderUtil.java:207) >>>>>> at >>>>>> >>>> >> org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOf(LoaderUtil.java:228) >>>>>> at >>>>>> >>>> >> org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOfProperty(LoaderUtil.java:253) >>>>>> at >>>>>> >>>> >> org.apache.logging.log4j.core.impl.Log4jContextFactory.createContextSelector(Log4jContextFactory.java:98) >>>>>> at >>>>>> >>>> >> org.apache.logging.log4j.core.impl.Log4jContextFactory.<init>(Log4jContextFactory.java:59) >>>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >> Method) >>>>>> at >>>>>> >>>> >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >>>>>> at >>>>>> >>>> >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>>>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423) >>>>>> at java.lang.Class.newInstance(Class.java:442) >>>>>> at org.apache.logging.log4j.LogManager.<clinit>(LogManager.java:94) >>>>>> at >>>>>> >>>> >> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:121) >>>>>> at >>>>>> >>>> >> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:49) >>>>>> at >>>>>> >>>> >> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46) >>>>>> at >>>>>> >>>> >> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29) >>>>>> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:355) >>>>>> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:380) >>>>>> at com.servoy.j2db.server.main.Activator.<clinit>(Activator.java:44) >>>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >> Method) >>>>>> at >>>>>> >>>> >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >>>>>> at >>>>>> >>>> >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>>>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423) >>>>>> at java.lang.Class.newInstance(Class.java:442) >>>>>> at >>>>>> >>>> >> org.eclipse.osgi.internal.framework.BundleContextImpl.loadBundleActivator(BundleContextImpl.java:763) >>>>>> at >>>>>> >>>> >> org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:716) >>>>>> at >>>>>> >>>> >> org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1002) >>>>>> at >>>>>> >>>> >> org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:354) >>>>>> at org.eclipse.osgi.container.Module.doStart(Module.java:581) >>>>>> at org.eclipse.osgi.container.Module.start(Module.java:449) >>>>>> at >>>> >> org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:468) >>>>>> at >>>>>> >>>> >> org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:114) >>>>>> at >>>>>> >>>> >> org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:505) >>>>>> at >>>>>> >>>> >> org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:328) >>>>>> at >>>>>> >>>> >> org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:392) >>>>>> at >>>>>> >>>> >> org.eclipse.osgi.internal.loader.sources.SingleSourcePackage.loadClass(SingleSourcePackage.java:36) >>>>>> at >>>>>> >>>> >> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:466) >>>>>> at >>>>>> >>>> >> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419) >>>>>> at >>>>>> >>>> >> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411) >>>>>> at >>>>>> >>>> >> org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150) >>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) >>>>>> >>>>>> >>>>>> On Fri, Sep 28, 2018 at 6:01 PM Ralph Goers < >> [email protected] >>>>> >>>>>> wrote: >>>>>> >>>>>>> All ContextSelectors are part of log4j-core, not log4j-api. >>>>>>> >>>>>>> Ralph >>>>>>> >>>>>>>> On Sep 28, 2018, at 7:59 AM, Rob Gansevles <[email protected]> >>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I would like to use the BasicContextSelector in our OSGI application >>>> so >>>>>>>> have a single global log4j connfiguration as described in >>>>>>>> http://logging.apache.org/log4j/2.x/manual/logsep.html >>>>>>>> >>>>>>>> However, BasicContextSelector lives in >>>>>>>> package org.apache.logging.log4j.core.selector which does not seem >> to >>>> be >>>>>>>> usable from log4j-api. >>>>>>>> >>>>>>>> This package is not imported in the manifest of log4j-api like other >>>>>>>> packages (for example org.apache.logging.log4j.core.async). >>>>>>>> >>>>>>>> Is this missing, or am I missing something? >>>>>>>> >>>>>>>> I am using log4j 2.11.1 >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Rob >>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > -- > Matt Sicker <[email protected]> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
