View Full Version : OSGi Manifest Exports and Imports
Oct 29th, 2009, 01:22 PM
I'm confused about OSGi Manifest Exports and Imports and how they relate to Spring Integration services. I'm looking at the Spring Integration 103 Samples Just Add OSGi blog entry (http://blog.springsource.com/2009/07/28/spring-integration-103-samples-just-add-osgi/).
The inbound bundle defines an "inboundService":
<osgi:service id="inboundService" ref="inboundChannel" interface="org.springframework.integration.channel.Subscribab leChannel"/>
The outbound bundle references a service called "filesIn":
<osgi:reference id="filesIn" interface="org.springframework.integration.channel.Subscribab leChannel"/>
My problem is I don't understand how "filesIn" links up with "inboundService". In its manifest the inbound bundle does export "org.springframework.integration.samples.osgi.inbou nd" but the outbound bundle does not import it in its manifest.
Like I said. I'm confused.
Oct 29th, 2009, 01:29 PM
The nice thing about this is it's actually a great example of loose coupling :) In fact, the outbound bundle doesn't have any direct dependency on any classes in the inbound bundle. It only needs to be aware of the Spring Integration core since its OSGi reference is pointing to a Message Channel.
Does that make sense?
Oct 29th, 2009, 01:58 PM
Let me try to clarify the confusion.
My problem is I don't understand how "filesIn" links up with "inboundService".
The linkage is based on osgi-inbound bundle publishing a service which advertises SubscribableChannel interface (<osgi:service/>) and osgi-outbound bundle binding to the service that advertises SubscribableChannel interface (<osgi:reference/>).
Since I only have one channel published as a service, the current configuration is sufficient enough. However lets assume I had two channels that were published as a service and both of them were advertising the SubscribableChannel interface. Then osgi-outbound bundle would have to choose which one to bind to. The default choice would be the service with the higher ranking or the lowest service.id, however if you need (in most cases you do) more granular control, osgi:service element will publish the service with a bean-name property so this way when you attempting to create a reference and bind to a service that derived with a bean with specific name you can use bean-name attribute as such:
<osgi:reference id="filesIn" interface="...SubscribableChannel" bean-name="inboundService"/>
Oct 29th, 2009, 02:01 PM
Thanks for the response.
So there is nothing in the outbound bundle ("filesIn") that ties it to the inbound bundle ("inboundService") and I was thinking that you needed that in an OSGi environment for one bundle to use another's services but what you're saying is SI handles that plumbing for me?
Decoupling is good but I'm guessing if there was an "outboundService2" it would also get the message from "inboundService". It would then need to make a determination as to whether it wanted to handle that message or not. Is that correct?
Okay I was struggling with how to explicitly tie to services together an I think I found my answer here: Bundle publishing two pub-sub chanels as OSgi service (http://forum.springsource.org/showthread.php?t=75316&referrerid=16535)
Oct 29th, 2009, 02:09 PM
Sorry... my response was a bit confusing, because I thought you were referring to package exports in the manifests.
It looks like Oleg has clarified things nicely in the meantime.
We're actually in the process of enhancing the OSGi support, so if you have any feedback on your experience please feel free to post here in the forum.
Oct 29th, 2009, 02:40 PM
Actually my question did have something to do with the package exports in the manifest. Since "filesIn" and "inboundService" clearly do not match I thought there must be some resolution in the OSGi manifest. There wasn't.
Oleg's and your explanation along with the link to the earlier thread make what's happening clearer. Part of the problem was, being as I was in OSGi, I felt like I just had to export something.
Thanks for the help,
Powered by vBulletin® Version 4.2.1 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.