Personally, I would rather duplicate the code, as much as it pains me to do that.
Ralph > On Oct 3, 2018, at 1:37 PM, Rob Gansevles <rgansev...@gmail.com> wrote: > > This patch is not effective in case of the BasicContextSelector because > package org.apache.logging.log4j.core.selector was not included in the > imports. > Only org.apache.logging.log4j.core.osgi, org.apache.logging.log4j.core.util > and org.apache.logging.log4j.core.async are includes as optional imports in > log4j-api. > > If org.apache.logging.log4j.core.selector was added as well, > BasicContextSelector could be used in an OSGI application. > > > I agree that it is weird that log4j-api depends on log4j-core. > The only reason this is needed because the utility methods in log4j-api are > used to load the classes. > I did a small experiment where I copied > LoaderUtil.newCheckedInstanceOfProperty() from log4j-api to a utility class > in log4j-core. > This also fixes the problem because then dynamic classes are loaded from > core and can be found (since they are defined in core). > > It unfortunately introduces a lot of code duplication (5 methods from > LoaderUtil). > > What do you think, would this be a good idea instead and remove all > dependencies from log4j-api to log4j-core? > > Rob > > > > > > > > > > > > On Fri, Sep 28, 2018 at 7:38 PM Ralph Goers <ralph.go...@dslextreme.com> > wrote: > >> Despite what I said below, it seems that the patch for LOG4J2-920 was >> applied over 2 years ago so this should not be happening with 2.11.1. >> >> Ralph >> >>> On Sep 28, 2018, at 10:34 AM, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >>> >>> It sounds related to LOG4J2-920 but the solution provided there has to >> be incorrect. There is no way the Log4j API should be declaring any >> requirements on Log4j Core stuff, especially since the Log4j API doesn’t >> have a clue what a ContextSelector is. That is only use by the >> Log4jContextFactory. I suspect the problem is that LoaderUtil resides in >> log4j-api and since it is actually doing the loading it is causing the >> problem. That means we are either doing the loading wrong or there is >> something broken in OSGi. >>> >>> Ralph >>> >>>> On Sep 28, 2018, at 10:20 AM, Rob Gansevles <rgansev...@gmail.com> >> wrote: >>>> >>>> Yes, that makes sense, but it seems they are still loaded by the >> log4j-api. >>>> I guess this is the reason there are a few optional import-package >>>> declarations in the manifest-generation in the pom for log4j-api: >>>> >>>> <plugin> >>>> <groupId>org.apache.felix</groupId> >>>> <artifactId>maven-bundle-plugin</artifactId> >>>> <configuration> >>>> <instructions> >>>> <Export-Package>org.apache.logging.log4j.*</Export-Package> >>>> <Import-Package> >>>> sun.reflect;resolution:=optional, >>>> org.apache.logging.log4j.core.osgi;resolution:=optional, >>>> org.apache.logging.log4j.core.util;resolution:=optional, >>>> org.apache.logging.log4j.core.async;resolution:=optional, >>>> * >>>> </Import-Package> >>>> >>>> >> <Bundle-Activator>org.apache.logging.log4j.util.Activator</Bundle-Activator> >>>> <_fixupmessages>"Classes found in the wrong >>>> directory";is:=warning</_fixupmessages> >>>> </instructions> >>>> </configuration> >>>> </plugin> >>>> >>>> I get the error below when I use the BasicContextSelector, and when I >> add >>>> org.apache.logging.log4j.core.selector to the imports in the manifest it >>>> works. >>>> >>>> Maybe it is the same issue as discussed in LOG4J2-920 but then >>>> for BundleContextSelector and should a similar patch being applied. >>>> What do you think? >>>> >>>> ERROR StatusLogger Unable to create custom ContextSelector. Falling >> back to >>>> default. >>>> java.lang.ClassNotFoundException: >>>> org.apache.logging.log4j.core.selector.BasicContextSelector cannot be >> found >>>> by org.apache.logging.log4j.api_2.11.2.SNAPSHOT >>>> at >>>> >> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:508) >>>> at >>>> >> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419) >>>> at >>>> >> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411) >>>> at >>>> >> org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150) >>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) >>>> at java.lang.Class.forName0(Native Method) >>>> at java.lang.Class.forName(Class.java:264) >>>> at >> org.apache.logging.log4j.util.LoaderUtil.loadClass(LoaderUtil.java:168) >>>> at >>>> >> org.apache.logging.log4j.util.LoaderUtil.newInstanceOf(LoaderUtil.java:207) >>>> at >>>> >> org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOf(LoaderUtil.java:228) >>>> at >>>> >> org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOfProperty(LoaderUtil.java:253) >>>> at >>>> >> org.apache.logging.log4j.core.impl.Log4jContextFactory.createContextSelector(Log4jContextFactory.java:98) >>>> at >>>> >> org.apache.logging.log4j.core.impl.Log4jContextFactory.<init>(Log4jContextFactory.java:59) >>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >>>> at >>>> >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >>>> at >>>> >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423) >>>> at java.lang.Class.newInstance(Class.java:442) >>>> at org.apache.logging.log4j.LogManager.<clinit>(LogManager.java:94) >>>> at >>>> >> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:121) >>>> at >>>> >> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:49) >>>> at >>>> >> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46) >>>> at >>>> >> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29) >>>> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:355) >>>> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:380) >>>> at com.servoy.j2db.server.main.Activator.<clinit>(Activator.java:44) >>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >>>> at >>>> >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >>>> at >>>> >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423) >>>> at java.lang.Class.newInstance(Class.java:442) >>>> at >>>> >> org.eclipse.osgi.internal.framework.BundleContextImpl.loadBundleActivator(BundleContextImpl.java:763) >>>> at >>>> >> org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:716) >>>> at >>>> >> org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1002) >>>> at >>>> >> org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:354) >>>> at org.eclipse.osgi.container.Module.doStart(Module.java:581) >>>> at org.eclipse.osgi.container.Module.start(Module.java:449) >>>> at >> org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:468) >>>> at >>>> >> org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:114) >>>> at >>>> >> org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:505) >>>> at >>>> >> org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:328) >>>> at >>>> >> org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:392) >>>> at >>>> >> org.eclipse.osgi.internal.loader.sources.SingleSourcePackage.loadClass(SingleSourcePackage.java:36) >>>> at >>>> >> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:466) >>>> at >>>> >> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419) >>>> at >>>> >> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411) >>>> at >>>> >> org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150) >>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) >>>> >>>> >>>> On Fri, Sep 28, 2018 at 6:01 PM Ralph Goers <ralph.go...@dslextreme.com >>> >>>> wrote: >>>> >>>>> All ContextSelectors are part of log4j-core, not log4j-api. >>>>> >>>>> Ralph >>>>> >>>>>> On Sep 28, 2018, at 7:59 AM, Rob Gansevles <rgansev...@gmail.com> >> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I would like to use the BasicContextSelector in our OSGI application >> so >>>>>> have a single global log4j connfiguration as described in >>>>>> http://logging.apache.org/log4j/2.x/manual/logsep.html >>>>>> >>>>>> However, BasicContextSelector lives in >>>>>> package org.apache.logging.log4j.core.selector which does not seem to >> be >>>>>> usable from log4j-api. >>>>>> >>>>>> This package is not imported in the manifest of log4j-api like other >>>>>> packages (for example org.apache.logging.log4j.core.async). >>>>>> >>>>>> Is this missing, or am I missing something? >>>>>> >>>>>> I am using log4j 2.11.1 >>>>>> >>>>>> Regards, >>>>>> >>>>>> Rob >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org >>>>> >>>>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >>> For additional commands, e-mail: log4j-user-h...@logging.apache.org >>> >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-user-h...@logging.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org