On 6/27/11 15:29, Shamik Bandopadhyay wrote:
Hi,
I'm in the process of trying out hot deploy in using servicemix. As per
the documentation, all I need to do is to drop the bundle in the deploy
folder and servicmix will take care of deploying it. Here's what I did
followed by my questions.
I've a bundle foo-1.0.0.jar which exports bar-1.0.0.jar. Now, I added some
changes in bar-1.0.0.jar and changed the version to bar-1.1.0.jar. I then
copied the file to the deploy forlder and waited for a min (default polling
rate is 1 sec). When I ran the test case, it showed results from bar-1.0.0
instead of the new version. The servicemix log also pointed to the fact that
it was referring to bar-1.0.0.
Now,I changed the version back to bar-1.0.0, build the jar and copied it to
deploy folder. I ran the test case and was able to see the changes. So, it
works fine if I've the same version.
What I'm trying to understand is how to hot deploy a new version of a
running bundle. Is it supported by the hot deploy feature ? The doubt I've
is explained through the example below :
You might need to ask the ServiceMix guys how their hot deploy feature
works, but OSGi in general supports what you want to do.
In foo-1.0.0 pom file, I've imported bar-1.0.0 as
<Import-Package>com.bar;version=1.0.0</Import-Package>, which gets reflected
in the manifest as part of the import-package as well export-package.
Are you saying both foo and bar export the com.bar package? Is that
intended?
Now,if
I'm able to hot deploy bar-1.1.0 , how'll bundle foo's manifest going to be
updated ? Do I need to provide a version range in foo's pom so that any
update in bar is covered ?<Import-Package>com.bar;version=1.0.0,
2.0.0</Import-Package>.
Generally, all imports specify a version range, not just a single
precise version...you need to be concerned about the extent of the range
and then only expect changes within this range to be acceptable. For
example, if you import 'version=1.0.0' this is any version >= 1.0.0,
whereas 'version="[1.0.0,1.1.0)"' is every version from 1.0.0 to 1.1.0
but not including it. So, in short, the acceptable new versions depend
on the existing version range. If a new version of com.bar doesn't fall
into foo's version range, then you'll need to release a new version of
foo to update its import (and potentially any breaking changes).
-> richard
I'll appreciate if someone can clarify my doubts in this regard.
- Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
