« Do-It-yourself SaaS, a first step into the cloud? | Main | Building Social Capital: the secret to SOA success »

November 24, 2008


Paul Benedict

I am waiting until OSGI bundle information in jar manifests are honored inside a war. Will WAS 7 provide that?

Kirk Knoernschild

Not in WAS 7. WAS 7 confines the benefits of OSGi to WAS. Development teams cannot deploy OSGi bundles to WAS 7. The only way to take advantage of OSGi in WAS 7 is to embed OSGi within your application.

Joost Winne

Have you got any links to how exactly embed OSGi in a WAS (6.1) application?

As an example requirement (jar hell):
I want to use two jars inside a web application: 'a.jar' and 'b.jar', where 'a.jar' requires 'log4j.1.1.jar', and where 'b.jar' requires 'log4j.1.2.jar'.

Both 'a.jar' and 'b.jar' do not expose log4j.

How can I make this happen (using two versions of log4j in one web application)?
Can I simple put 'a.jar', 'b.jar', 'log4j.1.1.jar' and 'log4j.1.2.jar' in the WEB-INF/lib folder in the WAR file of the EAR file (and put those special OSGi manifest files entries in those jars) and let OSGi save the day in some way?

How can I make sure the WAS uses the OSGi classloader mechanism instead of loading all in the application classloader (which results in arbitrarely loading classes from the two log4j jars, mostly coming from version 1.1 because its jar name comes lexicograficly first)?

I don't want to use that commandline tool to install, start/stop libraries. I don't need the dynamic features. The only OSGi feature I really need is: "a seperate classloader for each jar".

All tutorials about OSGi start with explaining the console install/start/stop, but nobody explains OSGi in a J2EE environment, the main existence reason for Java?


Do you know if it's planned to be able to injection OSGI references into a EJB like we can do in JOnas ?

The comments to this entry are closed.

  • Burton Group Free Resources Stay Connected Stay Connected Stay Connected Stay Connected

Blog powered by Typepad