[ https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15185726#comment-15185726 ]
Matt Sicker commented on LOG4J2-400: ------------------------------------ I don't think this issue is feasible anymore. Maybe in log4j 3.0? ;) > [OSGi] 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 > 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.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org