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>
