[
https://issues.apache.org/jira/browse/LOG4J2-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker resolved LOG4J2-515.
--------------------------------
Fix Version/s: 3.0.0
Resolution: Fixed
In 2.x, we did this via an optional dependency on the OSGi API. In 3.0.0, we
were able to remove OSGi as a dependency entirely from log4j-api, log4j-core,
and log4j-plugins, as we are using some BND annotations instead that are not
needed at runtime.
> Support OSGi bundles without requiring OSGi dependencies.
> ---------------------------------------------------------
>
> Key: LOG4J2-515
> URL: https://issues.apache.org/jira/browse/LOG4J2-515
> Project: Log4j 2
> Issue Type: Epic
> Components: API, Appenders, Configurators, Core, Filters, Layouts,
> Receivers
> Affects Versions: 2.0-rc1
> Environment: OSGi, non-OSGi
> Reporter: Matt Sicker
> Priority: Major
> Labels: bundle, osgi
> Fix For: 3.0.0
>
>
> In order to properly support OSGi, we need to use a combination of ideas.
> # Packages and modules should be as coherent as possible. This makes bundling
> them into bundles and services significantly easier. Plus, it's a good idea
> anyway.
> # Use [Felix SCR
> annotations|http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html]
> in order to support more advanced OSGi concepts without requiring an
> explicit dependency on OSGi. This way, the annotations can be discarded or
> ignored by non-OSGi environments.
> # Provide more bundles. The core bundles, while a good start, could be
> further modularized.
> # Don't rely on class loader hacks. Instead, methods that need to use a class
> loader should always include a ClassLoader parameter. Class loader hacks can
> be used in centralized locations as a fallback mechanism where no advanced
> class loaders are provided.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
