[
https://issues.apache.org/jira/browse/LOG4J2-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15390202#comment-15390202
]
Ralf commented on LOG4J2-1467:
------------------------------
A few thoughts:
DynamicImport-Package:
DynamicImport-Package contradicts a basic idea of OSGi. That is, that every JAR
(aka Bundle) clearly describes its external dependencies. With that the OSGi
runtime knows at startup time, that all needed packages are available.
With DynamicImport-Packages, the class loader of the bundle is allowed to
search the exported packages of all other bundles at runtime, which might
result in ClassNotFound or in a class found with the wrong version.
>From the OSGi point of view DynamicImport-Package is a bad idea and in complex
>scenarios the result might be unpredictable.
Setting the ThreadContextClassLoader:
The LoaderUtil either use the TCCL or its own CL to load the requested class.
In a OSGi environment the TCCL is undefined. AFAIK there are OSGi frameworks
that set the TCCL to the bundle class loader, other might just set it to null.
Anyway in OSGi you cannot rely on the TCCL.
As Matt mentioned the TCCL could be set set befor calling LoaderUtil and reset
afterward.
This adds a hidden prerequisite to the LoaderUtil API. Not good.
(Also the method LoaderUtil.getThreadContextClassLoader() would be pointless.)
Refactoring the LoaderUtil methods:
The third way is to refactor the methods of LoaderUtil, so they require the
class loader to use as parameter. The result would be similar to setting the
TCCL, but it is clear, that a class loader must be provided. The "old methods"
should be deprecated.
(Again LoaderUtil.getThreadContextClassLoader() would be pointless.)
>From this three options I would prefer the last one.
There is one scenario that needs additional thinking: The caller of LoaderUtil
knows the name of the class to load, but has no idea which classloader should
be used.
> OSGi: Missing import package
> ----------------------------
>
> Key: LOG4J2-1467
> URL: https://issues.apache.org/jira/browse/LOG4J2-1467
> Project: Log4j 2
> Issue Type: Bug
> Components: API
> Affects Versions: 2.6.2
> Environment: Enterprise OSGi application
> Reporter: Ralf
>
> The Import-Package statement in log4j-api-2.6.2.jar is missing the package
> "org.apache.logging.log4j.core.lookup". This results in the following log
> output while starting a enterprise OSGi application:
> Blueprint Extender: 3 WARN JNDI lookup class is not available because this
> JRE does not support JNDI. JNDI string lookups will not be available,
> continuing configuration. java.lang.ClassNotFoundException:
> org.apache.logging.log4j.core.lookup.JndiLookup
> at java.lang.Class.forName(Class.java:256)
> at
> org.apache.logging.log4j.util.LoaderUtil.loadClass(LoaderUtil.java:122)
> at
> org.apache.logging.log4j.util.LoaderUtil.newInstanceOf(LoaderUtil.java:141)
> at
> org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOf(LoaderUtil.java:168)
> at
> org.apache.logging.log4j.core.util.Loader.newCheckedInstanceOf(Loader.java:301)
> at
> org.apache.logging.log4j.core.lookup.Interpolator.<init>(Interpolator.java:95)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.<init>(AbstractConfiguration.java:116)
> and
> Blueprint Extender: 3 WARN JMX runtime input lookup class is not available
> because this JRE does not support JMX. JMX lookups will not be available,
> continuing configuration. java.lang.ClassNotFoundException:
> org.apache.logging.log4j.core.lookup.JmxRuntimeInputArgumentsLookup
> (Stacktrace like above)
> As local fix I added 'DynamicImport-Package: *' to the MANIFEST.MF.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
