Re: Using BasicContextSelector in OSGI application
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
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 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 newCheckedInstanceOfProperty(final String
> > propertyName, final Class 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
> > 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 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
> >> 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 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 >
> 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
> 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
Re: Using BasicContextSelector in OSGI application
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 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 newCheckedInstanceOfProperty(final String
> propertyName, final Class 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
> 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 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
>> 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 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
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
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
Re: Using BasicContextSelector in OSGI application
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 newCheckedInstanceOfProperty(final String
propertyName, final Class 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
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 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
> 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 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
> >> 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
> >> 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
Re: Using BasicContextSelector in OSGI application
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 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 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 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 >> 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 >> 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 >> 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: org.apache.felix maven-bundle-plugin org.apache.logging.log4j.* 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, * >> >> org.apache.logging.log4j.util.Activator
Re: Using BasicContextSelector in OSGI application
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 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 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 > 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 > 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 > 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: > >> > >> > >> org.apache.felix > >> maven-bundle-plugin > >> > >> > >> org.apache.logging.log4j.* > >> > >> 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, > >> * > >> > >> > >> > > >> > org.apache.logging.log4j.util.Activator > >> <_fixupmessages>"Classes found in the wrong > >> directory";is:=warning > >> > >> > >> > >> > >> 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
Re: Using BasicContextSelector in OSGI application
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 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 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 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 >>> 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 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 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: >> >> >> org.apache.felix >> maven-bundle-plugin >> >> >> org.apache.logging.log4j.* >> >> 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, >> * >> >> >> >> org.apache.logging.log4j.util.Activator >> <_fixupmessages>"Classes found in the wrong >> directory";is:=warning >> >> >> >> >> 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
Re: Using BasicContextSelector in OSGI application
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 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 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 > > 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 > >> 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 > >> 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: > > > org.apache.felix > maven-bundle-plugin > > > org.apache.logging.log4j.* > > 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, > * > > > > >> > org.apache.logging.log4j.util.Activator > <_fixupmessages>"Classes found in the wrong > directory";is:=warning > > > > > 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 > > >> >
Re: Using BasicContextSelector in OSGI application
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 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 > 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 >> 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 >> 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: org.apache.felix maven-bundle-plugin org.apache.logging.log4j.* 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, * >> org.apache.logging.log4j.util.Activator <_fixupmessages>"Classes found in the wrong directory";is:=warning 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.(Log4jContextFactory.java:59) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at >>
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 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 > 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 > 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: > >> > >> > >> org.apache.felix > >> maven-bundle-plugin > >> > >> > >> org.apache.logging.log4j.* > >> > >> 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, > >> * > >> > >> > >> > org.apache.logging.log4j.util.Activator > >> <_fixupmessages>"Classes found in the wrong > >> directory";is:=warning > >> > >> > >> > >> > >> 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.(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
Re: Using BasicContextSelector in OSGI application
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 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 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: >> >> >> org.apache.felix >> maven-bundle-plugin >> >> >> org.apache.logging.log4j.* >> >> 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, >> * >> >> >> org.apache.logging.log4j.util.Activator >> <_fixupmessages>"Classes found in the wrong >> directory";is:=warning >> >> >> >> >> 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.(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.(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.(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 >>
Re: Using BasicContextSelector in OSGI application
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 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: > > >org.apache.felix >maven-bundle-plugin > > >org.apache.logging.log4j.* > > 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, > * > > > org.apache.logging.log4j.util.Activator ><_fixupmessages>"Classes found in the wrong > directory";is:=warning > > > > > 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.(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.(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.(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
Re: Using BasicContextSelector in OSGI application
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: org.apache.felix maven-bundle-plugin org.apache.logging.log4j.* 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, * org.apache.logging.log4j.util.Activator <_fixupmessages>"Classes found in the wrong directory";is:=warning 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.(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.(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.(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
Re: Using BasicContextSelector in OSGI application
All ContextSelectors are part of log4j-core, not log4j-api. Ralph > On Sep 28, 2018, at 7:59 AM, Rob Gansevles 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
