Wrapping the LoaderUltil (log4j-api) calls in Loader (log4j-core) like
below does work, I can load classes in core when I replace
LoaderUtil.newCheckedInstanceOfProperty()
with the proposed Loader.newCheckedInstanceOfProperty(), even when I
remove all dependencies in log4j-api to log4j-core in the manifest.
Shall I create a pull-request for this?
Rob
public static <T> T newCheckedInstanceOfProperty(final String
propertyName, final Class<T> clazz)
throws ClassNotFoundException, NoSuchMethodException,
InvocationTargetException, InstantiationException,
IllegalAccessException {
ClassLoader contextClassLoader =
Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(getClassLoader());
return LoaderUtil.newCheckedInstanceOfProperty(propertyName, clazz);
} finally {
if (contextClassLoader != null) {
Thread.currentThread().setContextClassLoader(contextClassLoader);
}
}
}
On Fri, Oct 5, 2018 at 9:47 PM Ralph Goers <ralph.go...@dslextreme.com>
wrote:
> 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
>
>
