[
https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13984125#comment-13984125
]
Łukasz Dywicki commented on LOG4J2-400:
---------------------------------------
4.3.0 is sufficient and widely used. 5.0.0 brings some new features but so far
they are not important from log4j point of view.
> 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, 2.0-rc1
> Environment: OSGi R4 / R5 (Apache Felix 4.x)
> Reporter: Roland Weiglhofer
> Priority: Critical
> Labels: Appender, Core, Dependency, OSGi, PluginManager,
> lightweight, optional
> Fix For: 2.0
>
> Attachments: Unbenannt.jpg
>
>
> 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. (I want
> a lightweight version without database and http stuff. I do not want to
> install libraries, which I do not need. All the (transitiv)
> log4j2-dependencies together are much bigger than my own application.)
> 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.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
