You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Mark Derricutt <ma...@talios.com> on 2010/07/19 03:51:15 UTC
Updating features...
Hi all,
I was wondering about best practices for updating features in a Karaf
based deployment.
In our current setup, we have our features XML file dropped into the
./deploy directory, and the feature ( our app ) loads up fine,
however, if I modify the feature file, either to change a
<configuation/> element, or change a <bundle/> reference, Karaf never
seems to pick up this change.
At this stage, we're not changing the version number of the feature,
but even when I also did that I didn't see Karaf update the running
bundles.
Am I missing something simple here?
Thanks,
Mark
--
Pull me down under...
Re: Updating features...
Posted by Mark Derricutt <ma...@talios.com>.
Aries Applications sound interesting. I like the idea of deploying a
single binary for my app rather than 20+ bundles which could be a
management nightmare - esp. given we're not really going to be running
with random mix'n'match bundles, but a single "release", makes life
easier for the admins as well know that "X" is installed, and I guess
easier for them to update rather than doing multiple bundles.
I wonder if a zip'd file that contains a self contained repository and
a set of feature XML files could be a midpoint.
--
Pull me down under...
On Tue, Jul 20, 2010 at 4:14 PM, Chris Custine <ch...@gmail.com> wrote:
> Spring DM has a packaging scheme, and the Aries project has another
> variation called
> Applications:http://incubator.apache.org/aries/applications.html. I think
> the Aries application concept is the best option for most uses, but I am not
> sure how far along the implementation is. At one point we had discussed
> adopting that implementation as a replacement for Features but I'll let
> Guillaume give his opinion on that.
Re: Updating features...
Posted by David Jencks <da...@yahoo.com>.
Aries Applications are pretty neat and have some great ideas, but currently the plan is that each application gets deployed into a separate isolation environment of some kind (this part isn't implemented yet). Unless that idea gets changed, they may be great for applications but won't be much use for assembling a server.
david jencks
On Jul 19, 2010, at 9:14 PM, Chris Custine wrote:
> You've definitely come across the big gap in functionality regarding the Uber packaging. You are right about the deployment admin spec and the bundle ownership issue was one of the issues that kept us from using it. Karaf "features" were created to kind of fill that gap until something more suitable came along, so even what we came up with has limitations.
>
> Spring DM has a packaging scheme, and the Aries project has another variation called Applications:http://incubator.apache.org/aries/applications.html. I think the Aries application concept is the best option for most uses, but I am not sure how far along the implementation is. At one point we had discussed adopting that implementation as a replacement for Features but I'll let Guillaume give his opinion on that.
>
> Chris
>
> --
> Chris Custine
> FUSESource :: http://fusesource.com
> My Blog :: http://blog.organicelement.com
> Apache ServiceMix :: http://servicemix.apache.org
> Apache Felix :: http://felix.apache.org
> Apache Directory Server :: http://directory.apache.org
>
>
> On Mon, Jul 19, 2010 at 20:26, Mark Derricutt <ma...@talios.com> wrote:
> Interesting, I just noticed that with having the <configuration>
> blocks inside the feature file, they reset/overwrite any changes made
> via the GUI when restarting. So I think I'll go away from sticking
> default settings in there.
>
> I understand where you're coming from with the features being rather
> static - I was then wondering what method people are generally using
> for deploying applications into their runtimes. OBR?
> Deployment-Packages?
>
> I like the idea of the deployment-package, having a single versioned
> .dp file that contains all of our apps bundles for version X which
> could be dropped into the ./deploy directory, but I had read somewhere
> in the compendium that if you deploy via a deployment-package, then
> the individual bundles can only be updated ALSO via a deployment
> package ( I've not yet tested this method tho ).
>
> It seems there's several options all with pros/cons - would be nice to
> see a "current best practice" doc...
>
> Mark
>
>
> --
> Pull me down under...
>
> On Mon, Jul 19, 2010 at 6:33 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> > For the configuration, I'm not sure how to handle the changes, as the
> > configuration in the feature is mostly an initial configuration but it
> > could be changed by users afterward, so I'm kinda tempted to say that
> > we would only register new properties and let existing ones as they
> > are.
>
Re: Updating features...
Posted by Chris Custine <ch...@gmail.com>.
You've definitely come across the big gap in functionality regarding the
Uber packaging. You are right about the deployment admin spec and the
bundle ownership issue was one of the issues that kept us from using it.
Karaf "features" were created to kind of fill that gap until something more
suitable came along, so even what we came up with has limitations.
Spring DM has a packaging scheme, and the Aries project has another
variation called Applications:
http://incubator.apache.org/aries/applications.html. I think the Aries
application concept is the best option for most uses, but I am not sure how
far along the implementation is. At one point we had discussed adopting
that implementation as a replacement for Features but I'll let Guillaume
give his opinion on that.
Chris
<http://incubator.apache.org/aries/applications.html>
--
Chris Custine
FUSESource :: http://fusesource.com
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Felix :: http://felix.apache.org
Apache Directory Server :: http://directory.apache.org
On Mon, Jul 19, 2010 at 20:26, Mark Derricutt <ma...@talios.com> wrote:
> Interesting, I just noticed that with having the <configuration>
> blocks inside the feature file, they reset/overwrite any changes made
> via the GUI when restarting. So I think I'll go away from sticking
> default settings in there.
>
> I understand where you're coming from with the features being rather
> static - I was then wondering what method people are generally using
> for deploying applications into their runtimes. OBR?
> Deployment-Packages?
>
> I like the idea of the deployment-package, having a single versioned
> .dp file that contains all of our apps bundles for version X which
> could be dropped into the ./deploy directory, but I had read somewhere
> in the compendium that if you deploy via a deployment-package, then
> the individual bundles can only be updated ALSO via a deployment
> package ( I've not yet tested this method tho ).
>
> It seems there's several options all with pros/cons - would be nice to
> see a "current best practice" doc...
>
> Mark
>
>
> --
> Pull me down under...
>
> On Mon, Jul 19, 2010 at 6:33 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> > For the configuration, I'm not sure how to handle the changes, as the
> > configuration in the feature is mostly an initial configuration but it
> > could be changed by users afterward, so I'm kinda tempted to say that
> > we would only register new properties and let existing ones as they
> > are.
>
Re: Updating features...
Posted by Mark Derricutt <ma...@talios.com>.
I think this sounds like a good way forward. I need to sort out Nexus and
OBR so I can try this out.
Out of curiosity - does the current mvn resolver also support version
ranges? That could be a somewhat usable solution as well, bounce the server
with a cleaned out ./data/cache directory and have the feature resolver pull
in the latest mvn bundle from a range ( mmmm, now I think about that, that
might not be a nice way to go, but would also be rather handy ).
--
Pull me down under...
On Tue, Jul 20, 2010 at 7:43 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> Since 2.0, features can leverage OBR so that OBR will be used to
> compute the transitive closure based on the list of bundles listed in
> the feature. It can be done by simply adding resolver="obr" to the
> feature element.
>
Re: Updating features...
Posted by Guillaume Nodet <gn...@gmail.com>.
On Tue, Jul 20, 2010 at 4:26 AM, Mark Derricutt <ma...@talios.com> wrote:
> Interesting, I just noticed that with having the <configuration>
> blocks inside the feature file, they reset/overwrite any changes made
> via the GUI when restarting. So I think I'll go away from sticking
> default settings in there.
>
> I understand where you're coming from with the features being rather
> static - I was then wondering what method people are generally using
> for deploying applications into their runtimes. OBR?
> Deployment-Packages?
Since 2.0, features can leverage OBR so that OBR will be used to
compute the transitive closure based on the list of bundles listed in
the feature. It can be done by simply adding resolver="obr" to the
feature element.
The problem with DeploymentAdmin is that you are limited to a single
version of a given bundle.
> I like the idea of the deployment-package, having a single versioned
> .dp file that contains all of our apps bundles for version X which
> could be dropped into the ./deploy directory, but I had read somewhere
> in the compendium that if you deploy via a deployment-package, then
> the individual bundles can only be updated ALSO via a deployment
> package ( I've not yet tested this method tho ).
Yeah, DeploymentAdmin is too limited. We're working inside the OSGi
alliance on something called composite bundles / subsystems that
would allow a nice deployment. Features could then be mapped to
subsystems in the future and slowly deprecated.
That said, I'm not opposed to make features evolve and add some
lifecycle management / update and all other kind of new stuff, quite
the opposite.
> It seems there's several options all with pros/cons - would be nice to
> see a "current best practice" doc...
>
> Mark
>
>
> --
> Pull me down under...
>
> On Mon, Jul 19, 2010 at 6:33 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>> For the configuration, I'm not sure how to handle the changes, as the
>> configuration in the feature is mostly an initial configuration but it
>> could be changed by users afterward, so I'm kinda tempted to say that
>> we would only register new properties and let existing ones as they
>> are.
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Updating features...
Posted by Mark Derricutt <ma...@talios.com>.
Interesting, I just noticed that with having the <configuration>
blocks inside the feature file, they reset/overwrite any changes made
via the GUI when restarting. So I think I'll go away from sticking
default settings in there.
I understand where you're coming from with the features being rather
static - I was then wondering what method people are generally using
for deploying applications into their runtimes. OBR?
Deployment-Packages?
I like the idea of the deployment-package, having a single versioned
.dp file that contains all of our apps bundles for version X which
could be dropped into the ./deploy directory, but I had read somewhere
in the compendium that if you deploy via a deployment-package, then
the individual bundles can only be updated ALSO via a deployment
package ( I've not yet tested this method tho ).
It seems there's several options all with pros/cons - would be nice to
see a "current best practice" doc...
Mark
--
Pull me down under...
On Mon, Jul 19, 2010 at 6:33 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> For the configuration, I'm not sure how to handle the changes, as the
> configuration in the feature is mostly an initial configuration but it
> could be changed by users afterward, so I'm kinda tempted to say that
> we would only register new properties and let existing ones as they
> are.
Re: Updating features...
Posted by Guillaume Nodet <gn...@gmail.com>.
This is an area which is not really well supported.
The first thing is that features are kinda supposed to be static. We
could however support upgrading from one version to another (and also
support some kind of SNAPSHOT which would be handy when updating a
file in the deploy folder). It could compute the set of bundles that
need to be installed and the set of bundles to uninstall and perform
the changes.
For the configuration, I'm not sure how to handle the changes, as the
configuration in the feature is mostly an initial configuration but it
could be changed by users afterward, so I'm kinda tempted to say that
we would only register new properties and let existing ones as they
are.
I've raise a JIRA issue for that:
https://issues.apache.org/jira/browse/KARAF-129
On Mon, Jul 19, 2010 at 03:51, Mark Derricutt <ma...@talios.com> wrote:
> Hi all,
>
> I was wondering about best practices for updating features in a Karaf
> based deployment.
>
> In our current setup, we have our features XML file dropped into the
> ./deploy directory, and the feature ( our app ) loads up fine,
> however, if I modify the feature file, either to change a
> <configuation/> element, or change a <bundle/> reference, Karaf never
> seems to pick up this change.
>
> At this stage, we're not changing the version number of the feature,
> but even when I also did that I didn't see Karaf update the running
> bundles.
>
> Am I missing something simple here?
>
> Thanks,
> Mark
>
>
>
> --
> Pull me down under...
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com