[
https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882482#comment-13882482
]
Matt Sicker commented on LOG4J2-400:
------------------------------------
Linking this to an epic for OSGi support.
> Provide Appender-Bundles
> ------------------------
>
> Key: LOG4J2-400
> URL: https://issues.apache.org/jira/browse/LOG4J2-400
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders, Core
> Affects Versions: 2.0-beta9
> Environment: OSGi R4 / R5 (Apache Felix 4.x)
> Reporter: Roland Weiglhofer
> Priority: Critical
> Labels: Appender, Core, Dependency, OSGi, PluginManager,
> lightweight, optional
>
> Instead of deploying all appenders in the core fragment, it would be much
> better if the customer can choose which appender he wants to provide. It's
> easy to hive the appender off in a separate bundle fragment. The host bundle
> is the API bundle. The Plugin Manager (core fragment) finds the deployed
> appenders in the classpath of the host bundle. The PluginManager should parse
> the class path in a separate thread (Startup-Hook) and only once at the start
> of the host bundle, but not for each call (when a consumer bundle aquires a
> logger). Make package-imports optional
> (<Import-Package>*;resolution:=optional</Import-Package>)!!!!
> This reduces the number of dependencies and reduces the startup time of the
> whole system.
> One possible solution for the Plugin Manager is to use the reflections plugin
> during the maven build process. This plugin lists all classes of a project
> within a xml file. This file can be marked as a bundle resource and is stored
> within the appender bundle fragment. The idea is that each appender fragment
> has its own class list. Because the bundle host (log4j2 core) sees all
> resources of its fragments it can load these class lists at runtime. Thus,
> the Plugin Manager gets only those appenders that are installed within
> deployed bundle fragements. The class list is created during the build
> process, the plugin manager must not parse the classpath at runtime. Log4j2
> uses a xml parser by default. An additional new dependency to a xml-parser
> library is not required.
> <plugin>
> <groupId>org.reflections</groupId>
> <artifactId>reflections-maven</artifactId>
> <version>0.9.8</version>
> <executions>
> <execution>
> <goals>
> <goal>reflections</goal>
> </goals>
> <phase>process-classes</phase>
> </execution>
> </executions>
> <configuration>
>
> <destinations>${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml</destinations>
> </configuration>
> </plugin>
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
