[
https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13964044#comment-13964044
]
Roland Weiglhofer commented on LOG4J2-400:
------------------------------------------
Keep in mind that many target systems run with OSGi-R3 and OSGi-R4 and with an
embedded JVM without annotation support (because of a enhanced security
requirements), e.g. remote terminal units of a building management system or
cars like BMWs using OSGi R3 for the built-in entertainment electronics. User
friendly apps provide a wide support for different systems. Thus, Log4j2 should
also support target devices with limited resources, limited processing power
and enhanced security requirements. So, many of the nice features of OSGi-R5
and OSGi-4 are to heavy.
My solution is not the best but meets the demands.
________________________________________
Requirements for a modular log4j2
1. OGSi-R3 and R4 compliant (eg. no javax !)
2. Modular Appenders and Features as it descript in JIRA LOG4j2-400!
3. less (transitive) dependencies at all. (The more constraints, the longer the
start time of the software) Import of non-required dependencies must be marked
as opptional.
4. low memory footprint
5. low computational effort at all (for target systems like PowerPC or ARM)
> 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. 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
