If you are explicitly passing around ClassLoaders then it would probably work correctly. But here we have Module B calling Module A to load a class in Module B using the default ClassLoader, which will be Module A’s ClassLoader.
We are currently not passing ClassLoaders to LoaderUtil. Ralph > On Oct 5, 2018, at 11:21 AM, Matt Sicker <boa...@gmail.com> wrote: > > Say module A calls a method in module B which provides a ClassLoader > argument. Module A provides its own CL to module B. Then module B invokes > load() from there. Does this mean module B is loading classes using its own > CL (which doesn't make sense), or is it loading module A's classes on > behalf of it? I haven't looked into the exact implementation, but I feel as > though such a security check to make sure the caller class is in the > ClassLoader being invoked would break even more programs and be inefficient > anyways. > > On Thu, 4 Oct 2018 at 16:08, Ralph Goers <ralph.go...@dslextreme.com> wrote: > >> 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 <boa...@gmail.com> 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 <ralph.go...@dslextreme.com> >> 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 <rgansev...@gmail.com> >> 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 < >> ralph.go...@dslextreme.com> >>>>> 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 < >> ralph.go...@dslextreme.com> >>>>>> 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 <rgansev...@gmail.com> >>>>>> 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 < >>>> ralph.go...@dslextreme.com >>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> All ContextSelectors are part of log4j-core, not log4j-api. >>>>>>>>> >>>>>>>>> Ralph >>>>>>>>> >>>>>>>>>> On Sep 28, 2018, at 7:59 AM, Rob Gansevles <rgansev...@gmail.com> >>>>>> 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: log4j-user-unsubscr...@logging.apache.org >>>>>>>>> For additional commands, e-mail: >> log4j-user-h...@logging.apache.org >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >>>>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >>>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org >>>>>> >>>>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org >>>> >>>> >>> >>> -- >>> Matt Sicker <boa...@gmail.com> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-user-h...@logging.apache.org >> >> > > -- > Matt Sicker <boa...@gmail.com> --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
