Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Virgo » Hot deployment and run-time modification to Plan artifacts(Clarification on Plan artifacts and how hot deployment and runtime modification can be performed on them)
Hot deployment and run-time modification to Plan artifacts [message #656590] Sun, 27 February 2011 03:39 Go to next message
Matt Fellows is currently offline Matt Fellows
Messages: 28
Registered: February 2011
Junior Member
Hi team,

I was wondering if somebody could please explain how it is possible to modify modules within a Plan at runtime, and possible provide a bit more information on plans as the Documentation doesn't really go into much detail.

I've run through the tutorial and (I think) I have a pretty good understanding of the basics. I've been able to create my own Spring MVC application which relies on several bundles and have used the Equinox console to swap them out dynamically during run-time successfully - which is of course what we want. This was done one-by-one using the install command or the pickup directory.

What I can't seem to be able to do is the same when using a plan. I like the feature of being able to explicitly set the loading order of modules, but would like the ability to swap at runtime - say for hot deployments without restarts.

If I can't change them dynamically at runtime, then why bother going to the hassle of bundling?

I could be missing something but some clarification would be great.

Cheers,
Matt
Re: Hot deployment and run-time modification to Plan artifacts [message #656697 is a reply to message #656590] Mon, 28 February 2011 08:06 Go to previous messageGo to next message
Glyn Normington is currently offline Glyn Normington
Messages: 1222
Registered: July 2009
Senior Member
Updating bundles in a plan is currently a bit of a strange thing. The reason is that plans refer to their bundles using type (bundle), symbolic name, and version. The reference is to a bundle in the repository. So, to update a bundle in plan, which can be driven via JMX (take a look at the plan mxbean using JConsole), you'd have to replace the bundle contents in the repository but with the exact same version - not a great versioning story. (This would be further complicated if the bundle was in a remote repository, but let's not go there for now.)

One enhancement that has been raised (in bug 327538) is the ability to define plans which refer to their artifacts, including bundles, by URI. This would be much more amenable to updating the artifacts.

There are of course good reasons for using bundles even if you are not interested in dynamic update, e.g. good software engineering practice of dividing a program into modules, reduced footprint (e.g. compared to bundling the same library JARs into numerous WAR files), reduced impact of changing a JAR at runtime, and cleaner handling of native code.
Re: Hot deployment and run-time modification to Plan artifacts [message #656999 is a reply to message #656697] Tue, 01 March 2011 10:19 Go to previous messageGo to next message
Matt Fellows is currently offline Matt Fellows
Messages: 28
Registered: February 2011
Junior Member
Thanks for the explanation Glyn.

> One enhancement that has been raised (in bug 327538) is the ability to define plans which refer to their artifacts, including bundles, by URI. This would be much more amenable to updating the artifacts.

This would be nice. Really, the goal is to get all of the benefits of simple bundles with the added bonus of organisation and control. The hot deployment of artifacts is really one of the key drivers of using OSGi in the project we are about to embark on.

At the moment, best practice (from what I understand) is to turn of the watched directories feature in Production, which would mean that any kind of hot deployment using plans would not be possible.

I think we'll use simple bundles for the time being.

> There are of course good reasons for using bundles even if you are not interested in dynamic update, e.g. good software engineering practice of dividing a program into modules, reduced footprint (e.g. compared to bundling the same library JARs into numerous WAR files), reduced impact of changing a JAR at runtime, and cleaner handling of native code.

My apologies, instead of saying "If I can't change them dynamically at runtime, then why bother going to the hassle of bundling?" what I meant to say was "... bundling them together in a plan".

Absolutely, creating bundles is the way to go!

Thanks for getting back so quickly.

Cheers,
Matt
Re: Hot deployment and run-time modification to Plan artifacts [message #657004 is a reply to message #656999] Tue, 01 March 2011 10:46 Go to previous messageGo to next message
Glyn Normington is currently offline Glyn Normington
Messages: 1222
Registered: July 2009
Senior Member
Matt Fellows wrote on Tue, 01 March 2011 10:19
Thanks for the explanation Glyn.

> One enhancement that has been raised (in bug 327538) is the ability to define plans which refer to their artifacts, including bundles, by URI. This would be much more amenable to updating the artifacts.

This would be nice. Really, the goal is to get all of the benefits of simple bundles with the added bonus of organisation and control. The hot deployment of artifacts is really one of the key drivers of using OSGi in the project we are about to embark on.

Perhaps you would like to add a comment to the bug to support its implementation.
Quote:


At the moment, best practice (from what I understand) is to turn of the watched directories feature in Production, which would mean that any kind of hot deployment using plans would not be possible.

I'm not sure this would stop you because it would not be necessary to rebuild the repository index if you are simply replacing the bundle in the local repository without changing its bundle version. The update should pick up the new file contents. You might like to play with this.

(I emphasised "local" above because we cache the contents of remote repositories using a secure hash of the bundle contents and that would of course change and need to be updated in the index.)
Quote:


I think we'll use simple bundles for the time being.

> There are of course good reasons for using bundles even if you are not interested in dynamic update, e.g. good software engineering practice of dividing a program into modules, reduced footprint (e.g. compared to bundling the same library JARs into numerous WAR files), reduced impact of changing a JAR at runtime, and cleaner handling of native code.

My apologies, instead of saying "If I can't change them dynamically at runtime, then why bother going to the hassle of bundling?" what I meant to say was "... bundling them together in a plan".

There are good reasons to use plans even without dynamic update. Plans provide clean structuring of groups of bundles, and optional scoping (with thread context class loading support) and atomicity.
Quote:


Absolutely, creating bundles is the way to go!

Thanks for getting back so quickly.

Cheers,
Matt


By the way, one possible enhancement to plans would be to allow a bundle reference in a plan to be re-resolved. Since the reference has a version range, it would then be possible to add an later version of the bundle to the repository and have it be picked up. But, as you observe, this would require the use of a watched repository in production which is not ideal because of the polling behaviour which soaks up some CPU and IO.

[Updated on: Tue, 01 March 2011 10:47]

Report message to a moderator

Re: Hot deployment and run-time modification to Plan artifacts [message #657027 is a reply to message #657004] Tue, 01 March 2011 11:56 Go to previous messageGo to next message
Matt Fellows is currently offline Matt Fellows
Messages: 28
Registered: February 2011
Junior Member
Quote:
By the way, one possible enhancement to plans would be to allow a bundle reference in a plan to be re-resolved. Since the reference has a version range, it would then be possible to add an later version of the bundle to the repository and have it be picked up. But, as you observe, this would require the use of a watched repository in production which is not ideal because of the polling behaviour which soaks up some CPU and IO.


That was pretty much how I expected the plan to behave. Although I didn't really make it clear in my initial post, that was how I was attempting to update the bundle (add a new version, uninstall the old).

Perhaps there is a lazy-load solution on a .plan deployment to /pickup or a way to trigger a one-time 'watch' on the local repository that allows for a new version of a bundle to be added at runtime without the side-effects of a constant watch. Just thinking out loud.

I think there is a 'sweet spot' for plans that just hasn't been realised yet, but I haven't been able to articulate the best way of achieving it.

I've updated the feature request as suggested.

Quote:
I'm not sure this would stop you because it would not be necessary to rebuild the repository index if you are simply replacing the bundle in the local repository without changing its bundle version. The update should pick up the new file contents. You might like to play with this.


I thought I did try this, perhaps I need to try again. However in Production as you say, proper versioning is something to look out for and this wouldn't seem best practice.

Thanks again.
Matt
Re: Hot deployment and run-time modification to Plan artifacts [message #657032 is a reply to message #657027] Tue, 01 March 2011 12:09 Go to previous message
Glyn Normington is currently offline Glyn Normington
Messages: 1222
Registered: July 2009
Senior Member
Thanks Matt. Our focus on update/refresh has definitely been development time in the past. I know several users want to exploit that capability at production time, so that is essentially a new use case, but with a sound base in OSGi.
Previous Topic:Exception: ...required property 'bundleContext' has not been set
Next Topic:Using Spring DM v2_0_0_M2 in Virgo 3.0.0M2
Goto Forum:
  


Current Time: Wed Oct 01 04:03:01 GMT 2014

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

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