You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Rob Gansevles <rg...@gmail.com> on 2018/10/03 20:37:44 UTC
Re: Using BasicContextSelector in OSGI application
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 <ra...@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 <ra...@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 <rg...@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.goers@dslextreme.com
> >
> >> wrote:
> >>
> >>> All ContextSelectors are part of log4j-core, not log4j-api.
> >>>
> >>> Ralph
> >>>
> >>>> On Sep 28, 2018, at 7:59 AM, Rob Gansevles <rg...@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-unsubscribe@logging.apache.org
> >>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>
> >>>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
Re: Using BasicContextSelector in OSGI application
Posted by Rob Gansevles <rg...@gmail.com>.
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 <ra...@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 <rg...@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 <ra...@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 <bo...@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 <ra...@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 <bo...@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.goers@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 <rg...@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.goers@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.goers@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 <
> rgansevles@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.goers@dslextreme.com
> >>>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> All ContextSelectors are part of log4j-core, not log4j-api.
> >>>>>>>>>>>
> >>>>>>>>>>> Ralph
> >>>>>>>>>>>
> >>>>>>>>>>>> On Sep 28, 2018, at 7:59 AM, Rob Gansevles <
> >> rgansevles@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-unsubscribe@logging.apache.org
> >>>>>>>>>>> For additional commands, e-mail:
> >>>> log4j-user-help@logging.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail:
> log4j-user-unsubscribe@logging.apache.org
> >>>>>>>>> For additional commands, e-mail:
> >> log4j-user-help@logging.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>>>>>> For additional commands, e-mail:
> log4j-user-help@logging.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Matt Sicker <bo...@gmail.com>
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>
> >>>>
> >>>
> >>> --
> >>> Matt Sicker <bo...@gmail.com>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
Re: Using BasicContextSelector in OSGI application
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <rg...@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 <ra...@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 <bo...@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 <ra...@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 <bo...@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 <ra...@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 <rg...@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.goers@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.goers@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 <rgansevles@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.goers@dslextreme.com
>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> All ContextSelectors are part of log4j-core, not log4j-api.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>>> On Sep 28, 2018, at 7:59 AM, Rob Gansevles <
>> rgansevles@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-unsubscribe@logging.apache.org
>>>>>>>>>>> For additional commands, e-mail:
>>>> log4j-user-help@logging.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>>>>> For additional commands, e-mail:
>> log4j-user-help@logging.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>
>>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Using BasicContextSelector in OSGI application
Posted by Rob Gansevles <rg...@gmail.com>.
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 <ra...@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 <bo...@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 <ra...@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 <bo...@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 <ra...@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 <rg...@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.goers@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.goers@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 <rgansevles@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.goers@dslextreme.com
> >>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> All ContextSelectors are part of log4j-core, not log4j-api.
> >>>>>>>>>
> >>>>>>>>> Ralph
> >>>>>>>>>
> >>>>>>>>>> On Sep 28, 2018, at 7:59 AM, Rob Gansevles <
> rgansevles@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-unsubscribe@logging.apache.org
> >>>>>>>>> For additional commands, e-mail:
> >> log4j-user-help@logging.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>>>>> For additional commands, e-mail:
> log4j-user-help@logging.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>
> >>>>
> >>>
> >>> --
> >>> Matt Sicker <bo...@gmail.com>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>
> >>
> >
> > --
> > Matt Sicker <bo...@gmail.com>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
Re: Using BasicContextSelector in OSGI application
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <bo...@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 <ra...@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 <bo...@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 <ra...@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 <rg...@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.goers@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.goers@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 <rg...@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.goers@dslextreme.com
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> All ContextSelectors are part of log4j-core, not log4j-api.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>>> On Sep 28, 2018, at 7:59 AM, Rob Gansevles <rg...@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-unsubscribe@logging.apache.org
>>>>>>>>> For additional commands, e-mail:
>> log4j-user-help@logging.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>
>>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
>
> --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Using BasicContextSelector in OSGI application
Posted by Matt Sicker <bo...@gmail.com>.
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 <ra...@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 <bo...@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 <ra...@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 <rg...@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.goers@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.goers@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 <rg...@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.goers@dslextreme.com
> >>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> All ContextSelectors are part of log4j-core, not log4j-api.
> >>>>>>>
> >>>>>>> Ralph
> >>>>>>>
> >>>>>>>> On Sep 28, 2018, at 7:59 AM, Rob Gansevles <rg...@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-unsubscribe@logging.apache.org
> >>>>>>> For additional commands, e-mail:
> log4j-user-help@logging.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>
> >>>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>
> >>
> >
> > --
> > Matt Sicker <bo...@gmail.com>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Using BasicContextSelector in OSGI application
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <bo...@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 <ra...@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 <rg...@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 <ra...@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 <ra...@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 <rg...@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.goers@dslextreme.com
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> All ContextSelectors are part of log4j-core, not log4j-api.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>>> On Sep 28, 2018, at 7:59 AM, Rob Gansevles <rg...@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-unsubscribe@logging.apache.org
>>>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>
>>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
>
> --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Using BasicContextSelector in OSGI application
Posted by Matt Sicker <bo...@gmail.com>.
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 <ra...@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 <rg...@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 <ra...@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 <ra...@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 <rg...@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.goers@dslextreme.com
> >>>
> >>>> wrote:
> >>>>
> >>>>> All ContextSelectors are part of log4j-core, not log4j-api.
> >>>>>
> >>>>> Ralph
> >>>>>
> >>>>>> On Sep 28, 2018, at 7:59 AM, Rob Gansevles <rg...@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-unsubscribe@logging.apache.org
> >>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Using BasicContextSelector in OSGI application
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <rg...@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 <ra...@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 <ra...@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 <rg...@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.goers@dslextreme.com
>>>
>>>> wrote:
>>>>
>>>>> All ContextSelectors are part of log4j-core, not log4j-api.
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Sep 28, 2018, at 7:59 AM, Rob Gansevles <rg...@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-unsubscribe@logging.apache.org
>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>
>>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org