logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-1467) OSGi: Missing import package
Date Fri, 22 Jul 2016 21:14:20 GMT

    [ 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message