>Are you just talking about moving stuff around into different directories?
Pretty much. It's rather simple structuring. It's not to increase the number of JAR files, but it does increase the number of packages. Let me give an example. Suppose we want to make the JMS support its own bundle (which makes sense as a bundle, but in a normal class path only environment, you would just use log4j-core where it's all in one and requires other JARs in the class path to enable optional features). Then here are the changes I'd make: In o.a.l.l.c.appender.JMSQueueAppender and JMSTopicAppender, I'd put those in o.a.l.l.c.appender.jms. Then, in o.a.l.l.c.net, I'd move the six JMS classes there into o.a.l.l.c.net.jms. Really, when it comes down to it, OSGi usage isn't always about making a bazillion bundles. OSGi modularity is done at the package level. Thus, while one approach to using bundles is to split them up as much as possible, another common approach is to stick with your large JARs, but properly split up modules by packages. This makes it easier to keep internal classes private (in the OSGi sense; not a private class, but a private package) as well. Then there's the service approach which uses more of the OSGi layers. This is somewhat similar to Spring beans (which are actually one of the supported methods of configuring services and such in OSGi Blueprints). This can be done for log4j without screwing around with structure thanks to the existing @Plugin annotations which can be parsed into SCR metadata (or something similar). I think the best way to actually split up core into bundles is by major dependency groups. For instance, if you want to use JMS, you'd include the JMS bundle. If you want to use it with servlets, you would include the web bundle. If you want async support, include the async module. Basically, this helps isolate external dependencies in a more explicit way rather than the current method of manually having to include extra dependencies on your class path to support the optional features. Also, since we have all the bundles that would require, we could even include auto-setup in OSGi based on your config file! Wouldn't that be neat? Personally, I'd prefer the OSGi bundles to be configured differently than they are now, because the current method requires a shitload of extra pom files. It would be cool to just specify the metadata (perhaps the manifest file?) for each bundle to generate and let the build system create them from there. On 8 March 2014 18:31, Gary Gregory (JIRA) <j...@apache.org> wrote: > > [ > https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925065#comment-13925065] > > Gary Gregory commented on LOG4J2-400: > ------------------------------------- > > I agree with Ralph. This is getting ridiculous. Supporting OSGi is one > thing but thus micro slicing and dicing is too much. Personally the less > jars the better for me. > > > 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 > > > > > > 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 > > -- Matt Sicker <boa...@gmail.com>
