logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Sicker (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-400) Provide Appender-Bundles
Date Sun, 27 Apr 2014 20:19:15 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13982453#comment-13982453

Matt Sicker commented on LOG4J2-400:

So that BundleTracker class is in R5, not R4.2 or R4.3. So much for that. We can still do
the old-style way of tracking bundles, though.

> 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

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message