felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Using Maven, Felix, and commons-logging together?
Date Thu, 07 Sep 2006 03:49:34 GMT
On Thursday 07 September 2006 11:09, Tim Moloney wrote:
> I'm new to Felix and Maven so if these questions are documented
> somewhere, just show me the URL.

Have you read and understood Chapter 3 in the R4 spec, which deals with the 
module loader mechanism??

> On the other hand, Felix requires bundles which are "specialized" JAR files.
> How do Felix developers reconcile this?

By utilizing the OSGi plugin for Maven.

For so called Library Bundles that we just want legacy classes to be served 
from, need to be OSGified. Jason van Zyl has queried about making this a 
standard process in Maven2, to give us a huge hand in this process.
Meanwhile, and for non-Maven2 built projects, Felix is starting a "commons/" 
project to co-ordinate this effort.

> If I just include commons-logging
> because I want to use its SimpleLog, Felix wants everything that
> commons-logging could possibly be configured to use (avalon-framework,
> javax.servlet, logkit, and log4j).  

That means that you must be using the Maven plugin already, and only relies on 
the automatic generation of Import-Package statements.
That feature is cool, but more of a tool, than "always on". Take the generated 
packages, and weed-out those you know you don't need and put that into the 
relevant section in the configuration of the Maven plugin for your project.

> If I include all of these, Felix 
> wants the JAR file that contains com.sun.jdmk.comm.  What is the proper
> way to write my pom.xml so that the runtime "non-dependencies"
> (unconfigured loggers) aren't required just to load the bundle?

Word of caution, how do you know that they will remain unconfigured for all 
time? The beauty of OSGi is that things doesn't have to stop when you make 
upgrades or re-configure things. Log4J is a classic example; You load up 
(20min start time) your FAT WebSphere running a 24/7 application. Log4J is 
the logging system. 2 months later, someone decides that "well, getting logs 
via e-mail would be cool" and configures the MailAppender in Log4J, and it 
doesn't work because Java Mail API is missing. With OSGi, we can avoid these 
things, but it requires us to use our heads a bit more than in the past.

> Even if I managed to get all the dependencies working, I'll probably end
> up with a bundle containing all its possible dependency JAR files within
> it.  Since these dependencies are common libraries, other bundles might
> also include them which wastes space and could introduce conflicts.  I
> would think that someone has already solved these problems and there
> already exists a commons-logging bundle ready for use.  If so, I've been
> unable to find it.

Well, for the Logging problem, I am working on a fairly fancy one at OPS4J. It 
supports most logging APIs and re-routes to a Log4J backend. Your own bundle 
doesn't need to do anything special, only import the API package, such as 
org.apache.log4j. It allows you to reload the logging service without 
stopping your clients, enabling new APIs on-the-fly and so forth.
The Appender issue will be dealt with shortly as well.

> Perhaps I'm just missing a piece of the bigger picture that would make
> all of this make sense?

Yes. Probably; Don't put too much inside the Bundle, and rely on resolution of 
packages from other bundles.


View raw message