[ 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)