I have created a JIRA issue and a pull-request, see
https://issues.apache.org/jira/browse/LOG4J2-2482
Rob
On Sun, Oct 7, 2018 at 6:33 PM Ralph Goers <ralph.go...@dslextreme.com>
wrote:
> Yes please! If possible, please provide a test that would fail without the
> change but works with it.
>
> Ralph
>
> > On Oct 7, 2018, at 3:26 AM, Rob Gansevles <rgansev...@gmail.com> wrote:
> >
> > 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
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>
