logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Using BasicContextSelector in OSGI application
Date Sun, 07 Oct 2018 16:33:01 GMT
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 <rgansevles@gmail.com> wrote:
> 
> Wrapping the LoaderUltil (log4j-api) calls in Loader (log4j-core) like
> below does work, I can load classes in core when I replace
> LoaderUtil.newCheckedInstanceOfProperty()
> with the proposed  Loader.newCheckedInstanceOfProperty(), even when I
> remove all dependencies in log4j-api to log4j-core in the manifest.
> 
> Shall I create a pull-request for this?
> 
> Rob
> 
> public static <T> T newCheckedInstanceOfProperty(final String
> propertyName, final Class<T> clazz)
>        throws ClassNotFoundException, NoSuchMethodException,
> InvocationTargetException, InstantiationException,
>        IllegalAccessException {
>    ClassLoader contextClassLoader =
> Thread.currentThread().getContextClassLoader();
>    try {
>        Thread.currentThread().setContextClassLoader(getClassLoader());
>        return LoaderUtil.newCheckedInstanceOfProperty(propertyName, clazz);
>    } finally {
>        if (contextClassLoader != null) {
>            Thread.currentThread().setContextClassLoader(contextClassLoader);
>        }
>    }
> }
> 
> 
> On Fri, Oct 5, 2018 at 9:47 PM Ralph Goers <ralph.goers@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 <boards@gmail.com> wrote:
>>> 
>>> Say module A calls a method in module B which provides a ClassLoader
>>> argument. Module A provides its own CL to module B. Then module B invokes
>>> load() from there. Does this mean module B is loading classes using its
>> own
>>> CL (which doesn't make sense), or is it loading module A's classes on
>>> behalf of it? I haven't looked into the exact implementation, but I feel
>> as
>>> though such a security check to make sure the caller class is in the
>>> ClassLoader being invoked would break even more programs and be
>> inefficient
>>> anyways.
>>> 
>>> On Thu, 4 Oct 2018 at 16:08, Ralph Goers <ralph.goers@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 <boards@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 <rgansevles@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 <boards@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 <boards@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


Mime
View raw message