You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Filippo Diotalevi <fi...@gmail.com> on 2009/01/29 15:39:39 UTC
Managing a clustered OSGi application
Hi,
since I'm working on a OSGi application, I'm trying to understand
what are the best practices/reusable solutions to manage a clustered
OSGi application.
As (I guess) every typical OSGi application, the requirement is to be
able to upgrade at runtime the bundles, and add new ones. Of course
I'd like make this upgrade/deployment as simple as possible.
My questions
- where should the bundle be store? a Maven repo? a simple Apache?
- is there any reusable solution/projects to deploy a bundle
instantaneously in all the nodes of the cluster? to start/stop bundles
in all the nodes?
Any experience?
Many thanks,
--
Filippo Diotalevi
http://www.diotalevi.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Managing a clustered OSGi application
Posted by Jools <jo...@gmail.com>.
Hi Filippo,
You may want to have a look at newton -
http://newton.codecauldron.org/site/index.html
>From the Newton front page...
Newton is a distributed OSGi framework in which the components can be simple
POJOs or wrappers around components based on other models.
Newton recognises the dynamic nature of distributed computing and seeks to
address the needs of components living in this world. To this end Newton
moves code around the network installing it on demand and removing it when
it is no longer in use. Newton also dynamically wires up runtime service
dependencies between components and rewires them as service provider
components come and go.
Best regards,
Jools Enticknap
2009/1/29 Filippo Diotalevi <fi...@gmail.com>
> Hi,
> since I'm working on a OSGi application, I'm trying to understand
> what are the best practices/reusable solutions to manage a clustered
> OSGi application.
>
> As (I guess) every typical OSGi application, the requirement is to be
> able to upgrade at runtime the bundles, and add new ones. Of course
> I'd like make this upgrade/deployment as simple as possible.
>
> My questions
> - where should the bundle be store? a Maven repo? a simple Apache?
> - is there any reusable solution/projects to deploy a bundle
> instantaneously in all the nodes of the cluster? to start/stop bundles
> in all the nodes?
>
> Any experience?
>
> Many thanks,
> --
> Filippo Diotalevi
> http://www.diotalevi.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Managing a clustered OSGi application
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Filippo,
Filippo Diotalevi schrieb:
> Hi,
> since I'm working on a OSGi application, I'm trying to understand
> what are the best practices/reusable solutions to manage a clustered
> OSGi application.
>
> As (I guess) every typical OSGi application, the requirement is to be
> able to upgrade at runtime the bundles, and add new ones. Of course
> I'd like make this upgrade/deployment as simple as possible.
>
> My questions
> - where should the bundle be store? a Maven repo? a simple Apache?
> - is there any reusable solution/projects to deploy a bundle
> instantaneously in all the nodes of the cluster? to start/stop bundles
> in all the nodes?
>
> Any experience?
Two options come to mind: The simpler one is using the FileInstall
bundle pointing to a location which is shared by all cluster nodes.
The more complicated solution (which we use in Day's commercial
software), is to have a (clustered) JCR Repository to which the cluster
nodes connect and use Sling's JCRInstall bundle, which in effect then
does the same as FileInstall.
If you don't use a JCR Repository, you would probably be better served
with the first solution (FileInstall).
Regards
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org