This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes Other Application Frameworks and the fly likes osgi in action - chp 1 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "osgi in action - chp 1" Watch "osgi in action - chp 1" New topic
Author

osgi in action - chp 1

Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

If you ever received ClassNotFoundExceptions when starting your application
because the class path was not correct. OSGi can help you here by ensuring that code
dependencies are satisfied before allowing the code to execute.


How does osgi ensure that dependency are satisified. Can the author throw more light on the internal implementation details ?


Groovy
Travis Berthelot
Greenhorn

Joined: Oct 30, 2004
Posts: 24
It does so by dynamically loading Java Archives. That way you can use jars that are not in the class path.
Richard S. Hall
author
Ranch Hand

Joined: Feb 14, 2011
Posts: 47
Pradeep bhatt wrote:
How does osgi ensure that dependency are satisified. Can the author throw more light on the internal implementation details ?


Each bundle JAR file lists its dependencies on external code. The OSGi framework that reads this information at execution time and makes sure that other bundles have been deployed to satisfy the requirements. If not, you get an exception up front telling you some required code is missing.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Richard S. Hall wrote:
Pradeep bhatt wrote:
How does osgi ensure that dependency are satisified. Can the author throw more light on the internal implementation details ?


Each bundle JAR file lists its dependencies on external code. The OSGi framework that reads this information at execution time and makes sure that other bundles have been deployed to satisfy the requirements. If not, you get an exception up front telling you some required code is missing.


Wouldn't it burden the deployer to specify the external depedency. There is a chance it may be missed because the code uses say class.forname(..)
Richard S. Hall
author
Ranch Hand

Joined: Feb 14, 2011
Posts: 47
Pradeep bhatt wrote:
Wouldn't it burden the deployer to specify the external depedency. There is a chance it may be missed because the code uses say class.forname(..)


It relieves the deployer, since there is no more guess work. However, it does burden the module developer. Luckily, though, since OSGi dependencies are based on Java packages, a lot of this information can be automatically generated with tools like bnd.

Regarding Class.forName(), it is a good idea to avoid using that when using OSGi. In general, modules shouldn't have to be directly loading classes and if they must they must take care in doing so to avoid making assumptions about type visibility.

Anyway, worst case, missing a dependency is no worse than not knowing you should have put something on the class path. You'll just end up with a runtime exception that you'll have to fix, but hopefully you'll catch this in your testing.
Stuart McCulloch
author
Greenhorn

Joined: Feb 14, 2011
Posts: 21
Pradeep bhatt wrote:
Richard S. Hall wrote:
Pradeep bhatt wrote:
How does osgi ensure that dependency are satisified. Can the author throw more light on the internal implementation details ?


Each bundle JAR file lists its dependencies on external code. The OSGi framework that reads this information at execution time and makes sure that other bundles have been deployed to satisfy the requirements. If not, you get an exception up front telling you some required code is missing.


Wouldn't it burden the deployer to specify the external depedency. There is a chance it may be missed because the code uses say class.forname(..)

The developer is best placed to know what their bundle needs to import - that's why ideally OSGi metadata would already be available in third-party libraries to begin with. And once this metadata is available everyone else gets the benefit and they no longer have to guess what a library might require. How many times have you juggled with the classpath adding and moving various JARs around to fix some obscure exception?

Tools can help detect what you need to import, but as you say they can't detect all uses (such as dynamic Class.forName calls) - but then neither can users of your code unless they can see the source. At least OSGi gives you a way to tell other people what your code requires - and because this metadata uses a standard format it could even be used by other modularity frameworks in the future.
Augusto Sellhorn
Ranch Hand

Joined: May 24, 2007
Posts: 57
OSGi definitely has issues with libraries who use Class.forName() and there are a lot out there.

One of the challenges in writing OSGi compatible applications is that a lot of 3rd party libraries (most?) are not OSGi friendly in the first place. That's why you have things like bnd to help you wrap plain jar files into OSGi bundles, problem is things are not always very simple.

For example, we got weblogic JMS to work in an OSGi container but encountered a lot of issues, and it was not a trivial thing to make it work in OSGi. Things in this regard are a bit complicated when you introduce declarative frameworks like Spring. For example, Spring classes you use in a context are not scanned by the maven bundle plugin and it can't put packages in for you automagically :-(
Stuart McCulloch
author
Greenhorn

Joined: Feb 14, 2011
Posts: 21
Augusto Sellhorn wrote:For example, we got weblogic JMS to work in an OSGi container but encountered a lot of issues, and it was not a trivial thing to make it work in OSGi. Things in this regard are a bit complicated when you introduce declarative frameworks like Spring. For example, Spring classes you use in a context are not scanned by the maven bundle plugin and it can't put packages in for you automagically :-(

FYI, support for parsing Blueprint and Spring-DM XML for imported packages was added to the maven-bundle-plugin in version 2.0.1: https://issues.apache.org/jira/browse/FELIX-1552
Augusto Sellhorn
Ranch Hand

Joined: May 24, 2007
Posts: 57
Thanks!

Interesting, we're using version 2.0.1 and I wasn't aware of that feature. Probably not turning it on I guess ... (perhaps I have to tell it where the xml files are???)
Stuart McCulloch
author
Greenhorn

Joined: Feb 14, 2011
Posts: 21
Augusto Sellhorn wrote:Thanks!
Interesting, we're using version 2.0.1 and I wasn't aware of that feature. Probably not turning it on I guess ... (perhaps I have to tell it where the xml files are???)

It should be enabled by default and scan Spring-DM/Blueprint files that end up under META-INF/spring, META-INF/blueprint, or OSGI-INF/blueprint in the final bundle. I think there were some additional improvements in 2.1.0 but if you're still having trouble then send a message to the Apache Felix dev list http://felix.apache.org/site/mailinglists.html as we have several developers that use this feature in their projects (and know more about it than me :).
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Thanks for the tip. I will not use class.forName().. when using ogsi.
Mike Van
Ranch Hand

Joined: Apr 06, 2006
Posts: 83
Stuart McCulloch wrote:
Augusto Sellhorn wrote:Thanks!
Interesting, we're using version 2.0.1 and I wasn't aware of that feature. Probably not turning it on I guess ... (perhaps I have to tell it where the xml files are???)

It should be enabled by default and scan Spring-DM/Blueprint files that end up under META-INF/spring, META-INF/blueprint, or OSGI-INF/blueprint in the final bundle. I think there were some additional improvements in 2.1.0 but if you're still having trouble then send a message to the Apache Felix dev list http://felix.apache.org/site/mailinglists.html as we have several developers that use this feature in their projects (and know more about it than me :).


I thought it might be interesting for the group to explain exactly how a .jar file is made into a bundle using the maven-bundle-plugin. After your code is compiled, the maven-bundle-plugin (which is really just a sophisticated mavenized wrapper for bndlib) will scan all of your compiled class files for import statement. It will then list each of these under the Import-Package directive of your MANIFEST.MF file. The latest version of this plugin "should" also look for class references inside of you Spring and Aries files. The only real work a developer has to do is to check to ensure any jaxb files and spring/aries files not located in the directories you'd expect them to be in, have those files included in the maven bundle plugin's <Import-Package> section.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: osgi in action - chp 1