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,
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
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
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
>
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
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
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
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
>
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
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.
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.
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
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
>
13 matches
Mail list logo
