Ralph Goers commented on LOG4J2-2266:

Matt, PropertiesUtil was modified to use ServiceLoader.load without specifying 
a ClassLoader. That is problematic for OSGi users. See 
http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html for an 
explanation. When I implemented the Provider binding for LogManager I took this 
into account. In addition, it is possible that the implementation might not be 
found int the same ClassLoader as the caller. To handle this I tried to find 
all the ClassLoaders I could and loop through them. The mistake I made that is 
referenced in LOG4J2-2055 is that I end up looking at the same ClassLoader 
twice. That shouldn't be a big deal but it isn't correct and needs to be fixed. 
 Please take a look at ProviderUtil for how it deals with the ClassLoader. You 
will have to look at the Activator class in Log4j-API to see how it deals with 
Providers. You will need to do something similar for PropertySource to work 
properly in OSGi. I used the link above to guide me in getting the Provider to 
work with OSGi.

> Log4j2 throws NoClassDefFoundError in Java 8
> --------------------------------------------
>                 Key: LOG4J2-2266
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-2266
>             Project: Log4j 2
>          Issue Type: Bug
>    Affects Versions: 2.10.0
>            Reporter: Andrejus Chaliapinas
>            Priority: Major
> During Unit Tests run using JDK 8 and Log4j2 v2.10.0 - getting this as part 
> of exception stack:
> java.lang.NoClassDefFoundError: Could not initialize class 
>  org.apache.logging.log4j.util.PropertiesUtil
>      at 
> org.apache.logging.log4j.status.StatusLogger.<clinit>(StatusLogger.java:71)
>      at org.apache.logging.log4j.LogManager.<clinit>(LogManager.java:60)
> and issue seems to be somehow related to what is reported so far against JDK 
> 9 here: LOG4J2-2129.
> If some patch on top of v2.10.0 is available to test - please let me know 
> where to download it from.
> While running same UTs with same JDK 8 and v2.8.2 - issue is not observed.
> And question which I have here - why not introduce JDK8 compatibility runtime 
> mode while things with JDK9 are not yet that stable? So it could continue use 
> same logic as of v2.8.2 around that ServiceLoader and not cause side effects.

This message was sent by Atlassian JIRA

Reply via email to