You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by nprajeshgowda <np...@gmail.com> on 2014/02/19 16:02:25 UTC
Deployment of OSGi service bundles in Fuse ESB/SMX in production
Hi,
We have developed a product using servicemix and osgi. We are coming
up with process to patch the product when it goes to production.
We have use case where we have two different types of bundles and need
to know what is thebest way f patching them in production environment .
1. Bundles which have camel routes
2. OSGI service bundle which has code which creates camel routes and
custom logic of creating connection pool to db.
Say we have following in production
a. user-bnd-a-1.0.0 - has routes
b. user-camel-bnd-1.0.0 - has routes and db connection pool
Now in this case if we use the process of placing the latest artifact
say "user-bnd-a-1.0.1" to deploy folder, we will end up having two versions
of the artifact and both bundles will have db connection pool. with this one
of the connection pool is wasted. And we see routes created from only the
first bundle.
Can some one please help on how to patch in production environment and
how to over come the above said issue.
Br,
Rajesh
--
View this message in context: http://servicemix.396122.n5.nabble.com/Deployment-of-OSGi-service-bundles-in-Fuse-ESB-SMX-in-production-tp5719178.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Deployment of OSGi service bundles in Fuse ESB/SMX in production
Posted by John Dubchak <jo...@johndubchak.com>.
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.
>
Re: Deployment of OSGi service bundles in Fuse ESB/SMX in
production
Posted by nprajeshgowda <np...@gmail.com>.
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.
Re: Deployment of OSGi service bundles in Fuse ESB/SMX in production
Posted by Andrew Thorburn <nz...@gmail.com>.
You have a few choices - you should have a look at the Karaf user manual at
http://karaf.apache.org/manual/latest-2.2.x/users-guide/index.html (The
version bundled with SMX 4.5.3 is 2.2.11), but you've got some choices:
You can define your modules as Karaf Features. This isn't really ideal for
anything that needs regular upgrades, though, as you have to keep on adding
new feature URLs for every version (AFAIK), and it generally gets a bit
messy. Might be a good idea if you have a large number of bundles, only
some of which change at any given time.
You can delete the old version of the bundle from the deploy folder, which
will remove it from SMX, and then deploy the new version. Probably the most
straight-forward solution, though if there are exchanges in progress, Camel
/ SMX will wait up to 5 minutes before the bundle is forcibly removed, so
be careful of that.
Or, if you're using Maven, you can deploy the artifacts to $SMX/local-repo
(the folder doesn't exist by default), and then use the command
"bundle:install mvn:<groupId>/<artifactId>/<version>" to install the
bundle. This is a little more involved, as it gives back a Bundle ID which
you need to use to start the bundle with "bunde:start <bid>", as they don't
get auto-started after installation. You the uninstall the old bundle via
the SMX console before installing the new one. This is more of a manual
process, but it does provide more control over what is happening, and you
can be confident that once the uninstall command is done that the bundle is
*gone*. It's also probably more flexible, as you can setup remote maven
repositories to install from, if you don't want to copy to the file system.
I'm leaning towards the third solution myself, but I'm not sure how easy /
hard that will be to automate.
Thanks,
- Andrew
On Thu, Feb 20, 2014 at 4:02 AM, nprajeshgowda <np...@gmail.com>wrote:
> Hi,
>
> We have developed a product using servicemix and osgi. We are coming
> up with process to patch the product when it goes to production.
>
> We have use case where we have two different types of bundles and
> need
> to know what is thebest way f patching them in production environment .
>
> 1. Bundles which have camel routes
> 2. OSGI service bundle which has code which creates camel routes and
> custom logic of creating connection pool to db.
>
>
> Say we have following in production
> a. user-bnd-a-1.0.0 - has routes
> b. user-camel-bnd-1.0.0 - has routes and db connection pool
>
> Now in this case if we use the process of placing the latest artifact
> say "user-bnd-a-1.0.1" to deploy folder, we will end up having two versions
> of the artifact and both bundles will have db connection pool. with this
> one
> of the connection pool is wasted. And we see routes created from only the
> first bundle.
>
> Can some one please help on how to patch in production environment and
> how to over come the above said issue.
>
> Br,
> Rajesh
>
>
>
> --
> View this message in context:
> http://servicemix.396122.n5.nabble.com/Deployment-of-OSGi-service-bundles-in-Fuse-ESB-SMX-in-production-tp5719178.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>