[jira] [Updated] (LOG4J2-10) log4j 2.0 should work well with OSGi and Apache Felix

["Timothy Ward (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LOG4J2-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Timothy Ward updated LOG4J2-10:
-------------------------------

    Attachment: tests-and-version-ranges.patch

Hi,

As requested I've worked on a patch which improves the version ranges on the various log4j2 bundles, and also that adds a couple of simple OSGi sniff tests. Hopefully these can be used as a base to build a more comprehensive set of tests for the various appenders, but at the very least they prove that the bundles can be used successfully.

In the patch are the following changes:

Updates to various pom files. This corrects the version ranges and adds the maven dependencies for PAX Exam.

A new project for core-osgi-web, allowing the javax.servlet dependency to be separated from the dependency reduced core.

A new project for the OSGi sniff tests. This uses PAX Exam to launch an OSGi framework, and runs a couple of simple logging tests, once with the full core bundle, and once with the dependency reduced core bundle. This did flush out a couple of issues, fixes for which are included in the patch, and outlined below.

o.a.l.l.util.ProviderUtil - the change here is necessary to prevent the ThreadContextClassLoader (which is frequently the bootstrap classloader) from hiding the log4j implementation. Without this it is impossible to load the configuration or Classes for Log4J. The TCCL still takes precedence when loading things (which is definitely the right behaviour for Web Apps) but if nothing is found then the code falls back to using the Log4J classloader. 

o.a.l.l.core.config.LoggerConfig - this class was causing a cyclic package dependency on o.a.l.l.core.async and therefore causing problems in the dependency reduced bundle. As the only use of this package was to get the name of a class I simply replaced it with a literal. The class name was part of a client-set property, and so shouldn't ever change.

o.a.l.l.core.config.plugins - There is another cyclic package dependency between o.a.l.l.core and o.a.l.l.core.net. This is not possible to resolve without moving classes, so I have worked around it. This means that three classes from o.a.l.l.core.net are included in the dependency reduced bundle. As a result most of the classes in the dependency reduced bundle (e.g. the syslog layout) are usable, but some aren't (e.g. the JMSTopicAppender). These classes do work if you install the osgi-core-net fragment as well as the dependency reduced bundle, but in cases where you haven't we need to handle the ClassNotFound/NoClassDefFound. This has the side benefit of making those plugins unavailable unless their dependencies are satisfied.
                
> log4j 2.0 should work well with OSGi and Apache Felix
> -----------------------------------------------------
>
>                 Key: LOG4J2-10
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-10
>             Project: Log4j 2
>          Issue Type: Wish
>            Reporter: Curt Arnold
>         Attachments: reduced-dependency-bundles-2.patch, reduced-dependency-bundles.patch, tests-and-version-ranges.patch
>
>
> OSGi and specifically the Apache Felix implementation should be considered for framework services such as internal logging and configuration.
> log4j 2.0 should be able to be a provider of OSGi logging services.
> OSGi package visibility declarations should be used to distinguish between exported and explicitly supported APIs and implementation specific details. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org