Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Virgo » Order of bundle installation(How does Virgo determine what order to install bundles after a restart?)
Order of bundle installation [message #1262843] Tue, 04 March 2014 02:21 Go to next message
Virgo Noob is currently offline Virgo NoobFriend
Messages: 2
Registered: March 2014
Junior Member
How does Virgo determine what order to install bundles after a restart?
For example, I have two bundles that are being deployed via a JMX connection. The "client" bundle depends on the "core" bundle. So I install the core bundle first, and then the client. Then if I decide to later update the core bundle, it gets assigned a higher bundle ID. When I restart Virgo, it appears to try to install the client bundle first (since it had a lower ID) and since the core bundle is not there yet, the client will fail to install. Is there any way to get Virgo to "rescan" the bundles after all the bundles have been deployed and try again? Is it possible to get my desired outcome without using plans or pars?
Re: Order of bundle installation [message #1265621 is a reply to message #1262843] Thu, 06 March 2014 10:21 Go to previous messageGo to next message
Tin N/A is currently offline Tin N/AFriend
Messages: 46
Registered: December 2010
Member
I don't think you'll be able to do it without a plan/par, but I think your client is not appropriately decoupled if it does not start without the service. If you want to be true to OSGi and modularity concepts, the client bundle should install and start even when no service bundle is present. When the service becomes available, it will be wired in and your client can then do its work.
So either decouple the client, or merge it with the service into one bundle, whatever makes more sense in your situation because, as you described it, you're not really using the main benefits of OSGi modularity.
Re: Order of bundle installation [message #1265833 is a reply to message #1265621] Thu, 06 March 2014 16:18 Go to previous messageGo to next message
Virgo Noob is currently offline Virgo NoobFriend
Messages: 2
Registered: March 2014
Junior Member
So let's say my core bundle publishes a service interface class called INoob.java, and my client bundle consumes that service. Is the core bundle supposed to export the package containing INoob.java? If so, wouldn't that mean the client bundle would have to import that package in the MANIFEST.MF to load the interface class? That would mean the bundles still need to be installed in the correct order, otherwise the client bundle will fail to resolve. In my particular situation, I would not be able to merge the bundles together.
Re: Order of bundle installation [message #1266234 is a reply to message #1265833] Fri, 07 March 2014 06:20 Go to previous messageGo to next message
Tin N/A is currently offline Tin N/AFriend
Messages: 46
Registered: December 2010
Member
I see, so a standard way to deal with this would be to extract the interfaces into a non-service bundle. By "non-service bundle", I'm referring to the bundle that does not have to be started/activated. Those kind of bundles contain only interface/class definitions that other bundles would instance or use. And those bundles need not be deployed (by "deploy" I mean "copy and start") but rather you just put them in a repository and Virgo will resolve them when your client bundle imports the package.
Virgo offers an additional benefit for such a concept - it can monitor remote repositories so you can have a central place for all your Virgo instances where such bundles can be stored.
Re: Order of bundle installation [message #1270150 is a reply to message #1266234] Wed, 12 March 2014 14:55 Go to previous messageGo to next message
William Suetholz is currently offline William SuetholzFriend
Messages: 5
Registered: October 2013
Junior Member
So, interface only bundles are installed in a user repository, and Virgo will just notice when they appear?
How do you update the interface bundles?

Does this mean that the dependency should NOT be specified in the Manifest? What use is the manifest dependencies then, if the loader isn't smart enough to postpone loading bundles that don't have all their dependencies met?
Re: Order of bundle installation [message #1270166 is a reply to message #1270150] Wed, 12 March 2014 15:36 Go to previous messageGo to next message
William Suetholz is currently offline William SuetholzFriend
Messages: 5
Registered: October 2013
Junior Member
Let me expand on this a bit..

We recently migrated quite a few servlets to be OSGI specked jar's. Some were war's that we had originally been installing into Tomcat. Some were supporting jar's. One in particular was a utility jar that most of our other servlets depended on which is a JNI loading a DLL. Our packaging installs the bundles into Virgo using JMX controls, and every install of the package will update/install updated bundles. We have another package that installs additional servlets/bundles that also depend on this utility jar, which has ruled out solving this with a plan.

The migration followed a few simple steps..
1) Convert to Maven from Ant, including the source tree layout.
2) Modify the Manifest to add in OSGI information, including dependency and provides
3) Add bundle initialization routines if necessary.

In addition to migrating our bundles, we had to create and require some additional 3rd party bundles
supplying supporting tools, including a bundle for the JDBC jars for the database product we use, and
BIRT, AXIS2, Wicket, Spring Security, ...

At first glance (and second too) the port seemed to work very well. Everything in our infrastructure seemed to start and work.

After deploying in the field, and working on the next set of feature enhancements we started running into a few troubling problems.

1) The JNI bundle did not EVER seem to unload the DLL.
This caused us to have to stop and start Virgo completely when updating that bundle. Which happens every time we install a new "Base" package. This is a very time consuming process, since Virgo is taking up to 10 minutes before it's completely started, which is actually another problem, but we haven't even started to try to resolve that.
2) When stopping and starting Virgo, it didn't always load bundles in the same order, which meant that sometimes it wouldn't load the provider bundles before the dependent bundles (Which is how this message stays on topic)
3) Virgo startup times takes a long time before all the bundles are loaded and started..


We probably need to revisit the way that things were ported. Because it seems that the Virgo bundle loader isn't very intelligent about the Bundle Dependency resolution. Making sure to load and start provider bundles before the dependent bundles are started. Given the stated goal of OSGI to allow for bundles to be replaced easily, I believe that we were naive in the way that we expected things to work. But what use is the Bundle Dependency information in the Manifest if the loader doesn't use it to provide some sort of load order hints.

I am looking for more information on the best way to resolve these problems. One solution for the JNI situation that has been proposed, is to switch to JNA instead. From earlier comments in this thread, it sounds like we should be going one step further, and extracting out an interface first, and deploy that into the user-repository directory, and then have our bundle provide that interface. The other bundles would then depend on the interface bundle, not the provider bundle. Does that mean we need to do something special in the dependent bundle initialization routines? What happens when the provider bundle gets stopped or replaced? What happens when we want to add functionality to the interface? How are you supposed to replace bundles stored in the user repository?

Re: Order of bundle installation [message #1270572 is a reply to message #1270166] Thu, 13 March 2014 06:50 Go to previous message
Tin N/A is currently offline Tin N/AFriend
Messages: 46
Registered: December 2010
Member
Wow, that's quite a post. I'll try to answer a few points from my experience, although the core devs might have more insight.

So, the OSGi-way of updating your interface bundles would be to update (increase) their version number and deploy them to the repository. Manifest dependencies are used just for that - they don't have anything to do with OSGi services, they just tell what packages and what version of class definitions a bundle needs to run. Of course, when you update the interface bundle version, you also need to update the imports for all the bundles that use them (or use version ranges in imports so that minor updates to interface bundles are already accounted for).
A consequence of the above is that you'd want to re-wire your bundles to the new version of interface bundle. A core dev might have the best suggestion on how to do that, I'm not sure but maybe it can be done through JMX or from a gogo shell so you can shell-script it.
As for long Virgo startup times - I don't know how your bundle services are wired, but in your case they seem to work as if you're using spring-dm "single service" references. Those kind of references do indeed block the loading until a service reference is satisfied (i.e. they're "Waiting for service to become available"). However, there is also a "set reference" you can use where the bundle will start immediately, even though a service it references is not available. When it does become available, Virgo will wire the service into your bundle and you can use its reference from then on. This does require some additional checks in your code (testing to see if the service reference is not null), but it decouples your bundles completely and you can then independently remove and update any of them without the need to restart the whole server.

Hope that helps a bit...
Previous Topic:Virgo 3.7 RELEASE
Next Topic:Virgo 3.6.2 uses snaps and struts2
Goto Forum:
  


Current Time: Tue Dec 23 03:05:17 GMT 2014

Powered by FUDForum. Page generated in 0.02167 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software