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)
|
| Re: Hot deployment and run-time modification to Plan artifacts [message #656697 is a reply to message #656590] |
Mon, 28 February 2011 08:06   |
 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 |
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 |
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 |
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
|
|
| |
Goto Forum:
Current Time: Fri Dec 27 00:20:50 GMT 2024
Powered by FUDForum. Page generated in 0.04364 seconds |
] 
Search
Help
Register
Login
Home
