[
https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roland Weiglhofer updated LOG4J2-400:
-------------------------------------
Description:
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>
was:
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.
referes to LOG4J2-389 https://issues.apache.org/jira/browse/LOG4J2-389
> 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 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-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
