11

What I'd like to do is create a "launcher" framework for my code that, given a URL and a predefined versioning scheme: 1) go check if an update exists 2) download the updates 3) "install" the update 4) "re-run" the application

I want to a) do all of this inside of the existing JVM and b) be platform independent. Tall order right? Based on my (limited) knowledge of OSGi and Apache Felix I'm pretty sure this is possible, but I'm really getting lost in the details.

Checking for an update and downloading it is trivial. Causing the "old" bundle to unload and the "new" bundle to load is where I'm getting stuck. I've done OSGi work in the past but it was a lot less dynamic than this. A good starting place or a hard shove in the right direction would be most appreciated.

If I'm seriously over-baking something that's already been solved with a free library then tell me this too, but I haven't found anything so far. :-)

user453385
  • 113
  • 4

2 Answers2

7

You don't even need to download it, just check if an update is available and then call Bundle.update(InputStream) on the bundle that needs to be updated, generally followed by a call to PackageAdmin.refreshPackages() afterward.

Richard S. Hall
  • 71
  • 2
  • This will cause the previous bundle to unbind correct? What happens to the existing bundle after the update (i.e. on the hard drive)? – user453385 Aug 17 '11 at 18:10
  • Richard's answer is succinct and correct, see http://www.osgi.org/javadoc/r4v43/org/osgi/framework/Bundle.html#update%28java.io.InputStream%29 - the (old) bundle's state will be changed to UNINSTALLED in which case it's no longer available. Not sure what each of the framework's do - they'll certainly hold onto bundles between restarts, I'd imagine an uninstalled bundle is removed completely (both from JVM as long as garbage collection isn't impeded, as well as disk cache). OSGi is a perfect fit for your needs, which if flexible could be done simply with a maven repo and pax mvn url handler – earcam Aug 17 '11 at 20:31
  • The refresh causes the old bundle to "unbind" and become available for garbage collection. Directly after an update there are two revisions of the bundle on the hard drive and in memory, assuming that other bundles had dependencies on the updated bundle. This is why the refresh is necessary, since you want to have any dependent bundles switch to the new revision. Once the refresh happens, then there is only one revision of the updated bundle either in memory or on disk. – Richard S. Hall Aug 18 '11 at 15:47
  • What if update failed? Or what if the update is successful but have run-time bugs to warrant a rollback? I think issuing a rollback bundle as a new update would do nicely. – Augustus Thoo Nov 18 '11 at 03:10
4

you can check well-known provisioning solutions that can do all your steps instead of you (check for a new version, download, install/update, restart etc.)

  1. For Equinox framework: p2 http://www.eclipse.org/equinox/p2/
  2. For any OSGi R4 framework: Apache ACE http://incubator.apache.org/ace/a-brief-introduction.html

best regards, Dmytro

Dmytro Pishchukhin
  • 2,369
  • 1
  • 14
  • 19