Yes please! If possible, please provide a test that would fail without the
change but works with it.
Ralph
> On Oct 7, 2018, at 3:26 AM, Rob Gansevles <rgansev...@gmail.com> wrote:
>
> Wrapping the LoaderUltil (log4j-api) calls in Loader (log4j-core) like
> below does work, I can load classes in core when I replace
> LoaderUtil.newCheckedInstanceOfProperty()
> with the proposed Loader.newCheckedInstanceOfProperty(), even when I
> remove all dependencies in log4j-api to log4j-core in the manifest.
>
> Shall I create a pull-request for this?
>
> Rob
>
> public static <T> T newCheckedInstanceOfProperty(final String
> propertyName, final Class<T> clazz)
> throws ClassNotFoundException, NoSuchMethodException,
> InvocationTargetException, InstantiationException,
> IllegalAccessException {
> ClassLoader contextClassLoader =
> Thread.currentThread().getContextClassLoader();
> try {
> Thread.currentThread().setContextClassLoader(getClassLoader());
> return LoaderUtil.newCheckedInstanceOfProperty(propertyName, clazz);
> } finally {
> if (contextClassLoader != null) {
> Thread.currentThread().setContextClassLoader(contextClassLoader);
> }
> }
> }
>
>
> On Fri, Oct 5, 2018 at 9:47 PM Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
>
>> If you are explicitly passing around ClassLoaders then it would probably
>> work correctly. But here we have Module B calling Module A to load a class
>> in Module B using the default ClassLoader, which will be Module A’s
>> ClassLoader.
>>
>> We are currently not passing ClassLoaders to LoaderUtil.
>>
>> Ralph
>>
>>> On Oct 5, 2018, at 11:21 AM, Matt Sicker <boa...@gmail.com> wrote:
>>>
>>> Say module A calls a method in module B which provides a ClassLoader
>>> argument. Module A provides its own CL to module B. Then module B invokes
>>> load() from there. Does this mean module B is loading classes using its
>> own
>>> CL (which doesn't make sense), or is it loading module A's classes on
>>> behalf of it? I haven't looked into the exact implementation, but I feel
>> as
>>> though such a security check to make sure the caller class is in the
>>> ClassLoader being invoked would break even more programs and be
>> inefficient
>>> anyways.
>>>
>>> On Thu, 4 Oct 2018 at 16:08, Ralph Goers <ralph.go...@dslextreme.com>
>> wrote:
>>>
>>>> Matt, I don’t think that makes a difference when running in OSGi. The
>>>> problem is that core is calling API and asking it to load a core class.
>>>> Unless it has access to the class it can’t do it. In OSGi it will only
>> have
>>>> access if log4j-core exposes it.
>>>>
>>>> Ralph
>>>>
>>>>> On Oct 4, 2018, at 9:01 AM, Matt Sicker <boa...@gmail.com> wrote:
>>>>>
>>>>> LoaderUtil is using the thread context class loader by default. If it's
>>>> not
>>>>> set right, you can use of the methods there to specify the correct
>>>>> ClassLoader, or you can even push and pop TCCLs essentially.
>>>>>
>>>>> On Wed, 3 Oct 2018 at 16:46, Ralph Goers <ralph.go...@dslextreme.com>
>>>> wrote:
>>>>>
>>>>>> Personally, I would rather duplicate the code, as much as it pains me
>> to
>>>>>> do that.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>> On Oct 3, 2018, at 1:37 PM, Rob Gansevles <rgansev...@gmail.com>
>>>> wrote:
>>>>>>>
>>>>>>> This patch is not effective in case of the BasicContextSelector
>> because
>>>>>>> package org.apache.logging.log4j.core.selector was not included in
>> the
>>>>>>> imports.
>>>>>>> Only org.apache.logging.log4j.core.osgi,
>>>>>> org.apache.logging.log4j.core.util
>>>>>>> and org.apache.logging.log4j.core.async are includes as optional
>>>> imports
>>>>>> in
>>>>>>> log4j-api.
>>>>>>>
>>>>>>> If org.apache.logging.log4j.core.selector was added as well,
>>>>>>> BasicContextSelector could be used in an OSGI application.
>>>>>>>
>>>>>>>
>>>>>>> I agree that it is weird that log4j-api depends on log4j-core.
>>>>>>> The only reason this is needed because the utility methods in
>> log4j-api
>>>>>> are
>>>>>>> used to load the classes.
>>>>>>> I did a small experiment where I copied
>>>>>>> LoaderUtil.newCheckedInstanceOfProperty() from log4j-api to a utility
>>>>>> class
>>>>>>> in log4j-core.
>>>>>>> This also fixes the problem because then dynamic classes are loaded
>>>> from
>>>>>>> core and can be found (since they are defined in core).
>>>>>>>
>>>>>>> It unfortunately introduces a lot of code duplication (5 methods from
>>>>>>> LoaderUtil).
>>>>>>>
>>>>>>> What do you think, would this be a good idea instead and remove all
>>>>>>> dependencies from log4j-api to log4j-core?
>>>>>>>
>>>>>>> Rob
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Sep 28, 2018 at 7:38 PM Ralph Goers <
>>>> ralph.go...@dslextreme.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Despite what I said below, it seems that the patch for LOG4J2-920
>> was
>>>>>>>> applied over 2 years ago so this should not be happening with
>> 2.11.1.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>>> On Sep 28, 2018, at 10:34 AM, Ralph Goers <
>>>> ralph.go...@dslextreme.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> It sounds related to LOG4J2-920 but the solution provided there has
>>>> to
>>>>>>>> be incorrect. There is no way the Log4j API should be declaring any
>>>>>>>> requirements on Log4j Core stuff, especially since the Log4j API
>>>> doesn’t
>>>>>>>> have a clue what a ContextSelector is. That is only use by the
>>>>>>>> Log4jContextFactory. I suspect the problem is that LoaderUtil
>> resides
>>>> in
>>>>>>>> log4j-api and since it is actually doing the loading it is causing
>> the
>>>>>>>> problem. That means we are either doing the loading wrong or there
>> is
>>>>>>>> something broken in OSGi.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>>> On Sep 28, 2018, at 10:20 AM, Rob Gansevles <rgansev...@gmail.com
>>>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Yes, that makes sense, but it seems they are still loaded by the
>>>>>>>> log4j-api.
>>>>>>>>>> I guess this is the reason there are a few optional import-package
>>>>>>>>>> declarations in the manifest-generation in the pom for log4j-api:
>>>>>>>>>>
>>>>>>>>>> <plugin>
>>>>>>>>>> <groupId>org.apache.felix</groupId>
>>>>>>>>>> <artifactId>maven-bundle-plugin</artifactId>
>>>>>>>>>> <configuration>
>>>>>>>>>> <instructions>
>>>>>>>>>> <Export-Package>org.apache.logging.log4j.*</Export-Package>
>>>>>>>>>> <Import-Package>
>>>>>>>>>> sun.reflect;resolution:=optional,
>>>>>>>>>> org.apache.logging.log4j.core.osgi;resolution:=optional,
>>>>>>>>>> org.apache.logging.log4j.core.util;resolution:=optional,
>>>>>>>>>> org.apache.logging.log4j.core.async;resolution:=optional,
>>>>>>>>>> *
>>>>>>>>>> </Import-Package>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> <Bundle-Activator>org.apache.logging.log4j.util.Activator</Bundle-Activator>
>>>>>>>>>> <_fixupmessages>"Classes found in the wrong
>>>>>>>>>> directory";is:=warning</_fixupmessages>
>>>>>>>>>> </instructions>
>>>>>>>>>> </configuration>
>>>>>>>>>> </plugin>
>>>>>>>>>>
>>>>>>>>>> I get the error below when I use the BasicContextSelector, and
>> when
>>>> I
>>>>>>>> add
>>>>>>>>>> org.apache.logging.log4j.core.selector to the imports in the
>>>> manifest
>>>>>> it
>>>>>>>>>> works.
>>>>>>>>>>
>>>>>>>>>> Maybe it is the same issue as discussed in LOG4J2-920 but then
>>>>>>>>>> for BundleContextSelector and should a similar patch being
>> applied.
>>>>>>>>>> What do you think?
>>>>>>>>>>
>>>>>>>>>> ERROR StatusLogger Unable to create custom ContextSelector.
>> Falling
>>>>>>>> back to
>>>>>>>>>> default.
>>>>>>>>>> java.lang.ClassNotFoundException:
>>>>>>>>>> org.apache.logging.log4j.core.selector.BasicContextSelector cannot
>>>> be
>>>>>>>> found
>>>>>>>>>> by org.apache.logging.log4j.api_2.11.2.SNAPSHOT
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:508)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
>>>>>>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>>>>>>>>>> at java.lang.Class.forName0(Native Method)
>>>>>>>>>> at java.lang.Class.forName(Class.java:264)
>>>>>>>>>> at
>>>>>>>>
>>>> org.apache.logging.log4j.util.LoaderUtil.loadClass(LoaderUtil.java:168)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.apache.logging.log4j.util.LoaderUtil.newInstanceOf(LoaderUtil.java:207)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOf(LoaderUtil.java:228)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOfProperty(LoaderUtil.java:253)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.apache.logging.log4j.core.impl.Log4jContextFactory.createContextSelector(Log4jContextFactory.java:98)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.apache.logging.log4j.core.impl.Log4jContextFactory.<init>(Log4jContextFactory.java:59)
>>>>>>>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>>>>> Method)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>>>>>>>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>>>>>>>>>> at java.lang.Class.newInstance(Class.java:442)
>>>>>>>>>> at
>> org.apache.logging.log4j.LogManager.<clinit>(LogManager.java:94)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:121)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:49)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
>>>>>>>>>> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:355)
>>>>>>>>>> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:380)
>>>>>>>>>> at
>> com.servoy.j2db.server.main.Activator.<clinit>(Activator.java:44)
>>>>>>>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>>>>> Method)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>>>>>>>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>>>>>>>>>> at java.lang.Class.newInstance(Class.java:442)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.eclipse.osgi.internal.framework.BundleContextImpl.loadBundleActivator(BundleContextImpl.java:763)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:716)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1002)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:354)
>>>>>>>>>> at org.eclipse.osgi.container.Module.doStart(Module.java:581)
>>>>>>>>>> at org.eclipse.osgi.container.Module.start(Module.java:449)
>>>>>>>>>> at
>>>>>>>>
>>>>>>
>>>>
>> org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:468)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:114)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:505)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:328)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:392)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.eclipse.osgi.internal.loader.sources.SingleSourcePackage.loadClass(SingleSourcePackage.java:36)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:466)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
>>>>>>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Sep 28, 2018 at 6:01 PM Ralph Goers <
>>>>>> ralph.go...@dslextreme.com
>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> All ContextSelectors are part of log4j-core, not log4j-api.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>>> On Sep 28, 2018, at 7:59 AM, Rob Gansevles <
>> rgansev...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I would like to use the BasicContextSelector in our OSGI
>>>> application
>>>>>>>> so
>>>>>>>>>>>> have a single global log4j connfiguration as described in
>>>>>>>>>>>> http://logging.apache.org/log4j/2.x/manual/logsep.html
>>>>>>>>>>>>
>>>>>>>>>>>> However, BasicContextSelector lives in
>>>>>>>>>>>> package org.apache.logging.log4j.core.selector which does not
>> seem
>>>>>> to
>>>>>>>> be
>>>>>>>>>>>> usable from log4j-api.
>>>>>>>>>>>>
>>>>>>>>>>>> This package is not imported in the manifest of log4j-api like
>>>> other
>>>>>>>>>>>> packages (for example org.apache.logging.log4j.core.async).
>>>>>>>>>>>>
>>>>>>>>>>>> Is this missing, or am I missing something?
>>>>>>>>>>>>
>>>>>>>>>>>> I am using log4j 2.11.1
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Rob
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail:
>> log4j-user-unsubscr...@logging.apache.org
>>>>>>>>>>> For additional commands, e-mail:
>>>> log4j-user-h...@logging.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>>>>>>>>> For additional commands, e-mail:
>> log4j-user-h...@logging.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>>>>>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <boa...@gmail.com>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>>>
>>>>
>>>
>>> --
>>> Matt Sicker <boa...@gmail.com>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
