Hi,
Just my opinion, but the idea behind decomposing your application into
bundles, beyond a decoupled modular structure, is that you avoid bad
side-effects on dependent bundles when deploying new bundles.
Restarting SMX isn't necessary when a new bundle is deployed as the
container will see that a bundles dependencies are no longer available
and should transition its lifecycle to a non-running state. While there
are use-cases for restarting SMX, deployment of new OSGi bundles is not
one of them, IMO.
Simply deploying the new bundle and starting it *should* signal SMX to
transition the dependent bundle back to an Active (running) state.
Also, deploying a bundle and starting it can be accomplished in the same
step:
osgi:install -s ....
The "-s" above tells the installer to start the bundle if all of its
dependencies are resolved after the deployment.
John
On 2/19/14, 8:55 PM, nprajeshgowda wrote:
Hi,
I had tried the similar approach, but dint wanted to share the
approach and was looking if there are other approaches which is commonly
practiced in production environment.
Here is what i was trying.
1. Create a new bundle user-camel-bnd-1.0.1 and place it in
local-repo folder
2. Create a new karaf features file and place the xml file in
local-repo folder
3. Create a new "org.apache.karaf.features.cfg" which has the
latest karaf features version
4. Restart servicemix, so that the new features are loaded.
Is this a good approach ? or is there something which we can do
without restarting servicemix
With the approach you have specified, if we uninstall the old
osgi-bnd and place the new bundle in deploy, in case of servicemix restart
will the old bundle not come up ?? ending up in two bundles running.
Br,
Rajesh
--
View this message in context:
http://servicemix.396122.n5.nabble.com/Deployment-of-OSGi-service-bundles-in-Fuse-ESB-SMX-in-production-tp5719178p5719197.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
