You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Steve <de...@gmail.com> on 2013/11/15 17:36:45 UTC
Best practices around programmatic Feature manipulation (updating/self-updating)
Hello Karaf users,
I’m in the process of developing a provisioning agent for a
Karaf-based ESB (Fuse ESB/ServiceMix). Currently I’m using Features
exclusively as my unit of deployment as opposed to working directly
with individual bundles when provisioning. The Features mechanism is
quite nice and has been pleasant to work with programmatically via the
FeaturesService interface. In the course of developing this agent
though I’ve come up with a few questions, mostly related to
best-practices. I haven’t found answers in existing documentation; if
such information does exist, you have my apologies in advance for
troubling the mailing-list with something already answered elsewhere.
With that being said, here are my questions:
1.) A container has a Feature installed, “example-app”, at version
1.0. Now let’s say I decide I want to run version 1.1 at some point
down the road. Would the best practice be to first uninstall the
Feature at version 1.0 and then install version 1.1, or to just
install version 1.1 directly (skipping the explicit uninstall step)?
Currently I use the FeaturesService programmatically to uninstall the
old version prior to install the new. While this seems to work fine,
I thought it wise to inquire if there was an existing best practice
around this or, perhaps, potential pitfalls to be avoided.
2.) The provisioning agent itself is installed as part of a Feature.
I currently let the agent install a new version of its encapsulating
Feature. With other Features not associated with the agent, as I
mentioned in question #1, I explicitly uninstall the old version prior
to installing the new. For the agent I don’t do this to prevent a
“bundle-suicide” type of situation. When the agent installs a new
version of its encapsulating Feature this triggers an implicit
framework restart after which the new version is installed and the
older version uninstalled. Interestingly enough, if I try to go the
other direction, say from 1.1 back to 1.0, I get unfulfilled
dependencies that prevent the older version of the Feature from
installing (and both features end up uninstalled). The dependency in
question (commons-lang 3.x) is actually embedded in both version 1.0
and 1.1 of the bundle containing the application (both bundles are
identical except in version number for testing). I suspect the old
version is attempting to import packages from the new version’s
bundle, but fails to do so because the latter is then invalid. Should
I allow my agent to install a new version of its encapsulating Feature
or is this going down the wrong road? Is there a best practice (or
any advice) around a Feature self-update scenario?
I will greatly appreciate any information/advice that can be given
(even “RTFM” if you can point me to the right manual).
Thanks!
-Steve
Re: Best practices around programmatic Feature manipulation (updating/self-updating)
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
FYI, Fabric is a Apache licensed project from RedHat/Fuse, but not a
project from the Apache Software Foundation (it doesn't follow the same
policy in term of release/binding vote, etc).
The notion of profiles is in the Karaf roadmap (a bit different from the
Fabric profile).
It's the same for hawt.io (not part of Apache Software Foundation,
however under the Apache license).
Regards
JB
On 11/18/2013 09:49 AM, Claus Ibsen wrote:
> Hi
>
> You may want to take a look at Fuse Fabric
> https://github.com/jboss-fuse/fuse
> http://fuse.fusesource.org/fabric/
>
> Fuse Fabric : a provisioning, configuration and management solution
> for Apache Karaf, Apache ServiceMix and Fuse
>
> Fabric has the concept of profiles that allows you to describe/define
> what container(s) should be running. Then you can do rolling
> upgrades/downgrades of profiles on the containers.
>
> And you can have a git store so all the profiles is stored persistent
> and you have all the power of git, so you can look in the git commit
> logs for when/who did what, and versioning etc.
>
> On the containers a Fabric Agent is running to handle the provisioning
> and whatnot.
>
> Fuse Fabric comes out of the box in JBoss Fuse -
> http://www.jboss.org/products/fuse.
> And you have Fabric commands in the Karaf shell, and for web UI you
> have hawtio - http://hawt.io/
>
>
>
> On Fri, Nov 15, 2013 at 5:36 PM, Steve <de...@gmail.com> wrote:
>> Hello Karaf users,
>>
>> I’m in the process of developing a provisioning agent for a
>> Karaf-based ESB (Fuse ESB/ServiceMix). Currently I’m using Features
>> exclusively as my unit of deployment as opposed to working directly
>> with individual bundles when provisioning. The Features mechanism is
>> quite nice and has been pleasant to work with programmatically via the
>> FeaturesService interface. In the course of developing this agent
>> though I’ve come up with a few questions, mostly related to
>> best-practices. I haven’t found answers in existing documentation; if
>> such information does exist, you have my apologies in advance for
>> troubling the mailing-list with something already answered elsewhere.
>> With that being said, here are my questions:
>>
>>
>>
>> 1.) A container has a Feature installed, “example-app”, at version
>> 1.0. Now let’s say I decide I want to run version 1.1 at some point
>> down the road. Would the best practice be to first uninstall the
>> Feature at version 1.0 and then install version 1.1, or to just
>> install version 1.1 directly (skipping the explicit uninstall step)?
>> Currently I use the FeaturesService programmatically to uninstall the
>> old version prior to install the new. While this seems to work fine,
>> I thought it wise to inquire if there was an existing best practice
>> around this or, perhaps, potential pitfalls to be avoided.
>>
>>
>>
>> 2.) The provisioning agent itself is installed as part of a Feature.
>> I currently let the agent install a new version of its encapsulating
>> Feature. With other Features not associated with the agent, as I
>> mentioned in question #1, I explicitly uninstall the old version prior
>> to installing the new. For the agent I don’t do this to prevent a
>> “bundle-suicide” type of situation. When the agent installs a new
>> version of its encapsulating Feature this triggers an implicit
>> framework restart after which the new version is installed and the
>> older version uninstalled. Interestingly enough, if I try to go the
>> other direction, say from 1.1 back to 1.0, I get unfulfilled
>> dependencies that prevent the older version of the Feature from
>> installing (and both features end up uninstalled). The dependency in
>> question (commons-lang 3.x) is actually embedded in both version 1.0
>> and 1.1 of the bundle containing the application (both bundles are
>> identical except in version number for testing). I suspect the old
>> version is attempting to import packages from the new version’s
>> bundle, but fails to do so because the latter is then invalid. Should
>> I allow my agent to install a new version of its encapsulating Feature
>> or is this going down the wrong road? Is there a best practice (or
>> any advice) around a Feature self-update scenario?
>>
>>
>> I will greatly appreciate any information/advice that can be given
>> (even “RTFM” if you can point me to the right manual).
>>
>>
>> Thanks!
>>
>> -Steve
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Best practices around programmatic Feature manipulation (updating/self-updating)
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Nov 18, 2013 at 1:12 PM, Achim Nierbeck <bc...@googlemail.com> wrote:
> It's very funny to see this advertisements for Fuse Fabric and Hawt.IO
> again.
>
It was not intended as an advertisement.
Its referring to a project that already does what the user mentions he
wants to build on his own.
The user mentioned developing a Karaf based provision agent. Which
Fuse Fabric is.
And he mentions Fuse ESB which comes out of the box included with Fuse
Fabric; and hawtio in the upcoming JBoss Fuse 6.1 release.
> As this is the Apache Karaf mailing-list I would expect solutions for
> working with Apache Karaf.
Fuse Fabric *works with Karaf*. In fact it currently only runs on top of Karaf.
Though there is work in process to make Fuse Fabric run on other
containers such as Apache Tomcat, JBoss WildFly, and any other
widespread in use containers (OSGi and non-OSGi); giving end users
more choices; as not everyone can use Karaf based containers.
> If those things are so great, why don't you donate it back to Apache Karaf?
Well in fact Fuse Fabric is in the process of being donated to ASF.
Layers is involved and they are taking their time - in fact they are
taking very long time.
Until they give the go ahead, all we can do is wait.
> This way we're back to one community.
>
Apache is not about everything must be a ASF project.
For example Apache Karaf is using a number of projects outside ASF in
its distribution.
- osgi
- eclipse equionox (if you switch from felix)
- eclipse jetty
- ops4j
- asm
- jline
- service wrappers
- spring ???
So should all these projects be donated to ASF?
Fabric is in fact optional you can run on top of Karaf.
But most of these projects mentioned above, is mandatory to run Karaf.
And they are not ASF projects.
> just my 0.02€
>
> regards, Achim
>
>
> 2013/11/18 Claus Ibsen <cl...@gmail.com>
>>
>> Hi
>>
>> You may want to take a look at Fuse Fabric
>> https://github.com/jboss-fuse/fuse
>> http://fuse.fusesource.org/fabric/
>>
>> Fuse Fabric : a provisioning, configuration and management solution
>> for Apache Karaf, Apache ServiceMix and Fuse
>>
>> Fabric has the concept of profiles that allows you to describe/define
>> what container(s) should be running. Then you can do rolling
>> upgrades/downgrades of profiles on the containers.
>>
>> And you can have a git store so all the profiles is stored persistent
>> and you have all the power of git, so you can look in the git commit
>> logs for when/who did what, and versioning etc.
>>
>> On the containers a Fabric Agent is running to handle the provisioning
>> and whatnot.
>>
>> Fuse Fabric comes out of the box in JBoss Fuse -
>> http://www.jboss.org/products/fuse.
>> And you have Fabric commands in the Karaf shell, and for web UI you
>> have hawtio - http://hawt.io/
>>
>>
>>
>> On Fri, Nov 15, 2013 at 5:36 PM, Steve <de...@gmail.com> wrote:
>> > Hello Karaf users,
>> >
>> > I’m in the process of developing a provisioning agent for a
>> > Karaf-based ESB (Fuse ESB/ServiceMix). Currently I’m using Features
>> > exclusively as my unit of deployment as opposed to working directly
>> > with individual bundles when provisioning. The Features mechanism is
>> > quite nice and has been pleasant to work with programmatically via the
>> > FeaturesService interface. In the course of developing this agent
>> > though I’ve come up with a few questions, mostly related to
>> > best-practices. I haven’t found answers in existing documentation; if
>> > such information does exist, you have my apologies in advance for
>> > troubling the mailing-list with something already answered elsewhere.
>> > With that being said, here are my questions:
>> >
>> >
>> >
>> > 1.) A container has a Feature installed, “example-app”, at version
>> > 1.0. Now let’s say I decide I want to run version 1.1 at some point
>> > down the road. Would the best practice be to first uninstall the
>> > Feature at version 1.0 and then install version 1.1, or to just
>> > install version 1.1 directly (skipping the explicit uninstall step)?
>> > Currently I use the FeaturesService programmatically to uninstall the
>> > old version prior to install the new. While this seems to work fine,
>> > I thought it wise to inquire if there was an existing best practice
>> > around this or, perhaps, potential pitfalls to be avoided.
>> >
>> >
>> >
>> > 2.) The provisioning agent itself is installed as part of a Feature.
>> > I currently let the agent install a new version of its encapsulating
>> > Feature. With other Features not associated with the agent, as I
>> > mentioned in question #1, I explicitly uninstall the old version prior
>> > to installing the new. For the agent I don’t do this to prevent a
>> > “bundle-suicide” type of situation. When the agent installs a new
>> > version of its encapsulating Feature this triggers an implicit
>> > framework restart after which the new version is installed and the
>> > older version uninstalled. Interestingly enough, if I try to go the
>> > other direction, say from 1.1 back to 1.0, I get unfulfilled
>> > dependencies that prevent the older version of the Feature from
>> > installing (and both features end up uninstalled). The dependency in
>> > question (commons-lang 3.x) is actually embedded in both version 1.0
>> > and 1.1 of the bundle containing the application (both bundles are
>> > identical except in version number for testing). I suspect the old
>> > version is attempting to import packages from the new version’s
>> > bundle, but fails to do so because the latter is then invalid. Should
>> > I allow my agent to install a new version of its encapsulating Feature
>> > or is this going down the wrong road? Is there a best practice (or
>> > any advice) around a Feature self-update scenario?
>> >
>> >
>> > I will greatly appreciate any information/advice that can be given
>> > (even “RTFM” if you can point me to the right manual).
>> >
>> >
>> > Thanks!
>> >
>> > -Steve
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> Red Hat, Inc.
>> Email: cibsen@redhat.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>
>
>
>
> --
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
> Commiter & Project Lead
> blog <http://notizblog.nierbeck.de/>
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: Best practices around programmatic Feature manipulation (updating/self-updating)
Posted by Achim Nierbeck <bc...@googlemail.com>.
It's very funny to see this advertisements for Fuse Fabric and Hawt.IO
again.
As this is the Apache Karaf mailing-list I would expect solutions for
working with Apache Karaf.
If those things are so great, why don't you donate it back to Apache Karaf?
This way we're back to one community.
just my 0.02€
regards, Achim
2013/11/18 Claus Ibsen <cl...@gmail.com>
> Hi
>
> You may want to take a look at Fuse Fabric
> https://github.com/jboss-fuse/fuse
> http://fuse.fusesource.org/fabric/
>
> Fuse Fabric : a provisioning, configuration and management solution
> for Apache Karaf, Apache ServiceMix and Fuse
>
> Fabric has the concept of profiles that allows you to describe/define
> what container(s) should be running. Then you can do rolling
> upgrades/downgrades of profiles on the containers.
>
> And you can have a git store so all the profiles is stored persistent
> and you have all the power of git, so you can look in the git commit
> logs for when/who did what, and versioning etc.
>
> On the containers a Fabric Agent is running to handle the provisioning
> and whatnot.
>
> Fuse Fabric comes out of the box in JBoss Fuse -
> http://www.jboss.org/products/fuse.
> And you have Fabric commands in the Karaf shell, and for web UI you
> have hawtio - http://hawt.io/
>
>
>
> On Fri, Nov 15, 2013 at 5:36 PM, Steve <de...@gmail.com> wrote:
> > Hello Karaf users,
> >
> > I’m in the process of developing a provisioning agent for a
> > Karaf-based ESB (Fuse ESB/ServiceMix). Currently I’m using Features
> > exclusively as my unit of deployment as opposed to working directly
> > with individual bundles when provisioning. The Features mechanism is
> > quite nice and has been pleasant to work with programmatically via the
> > FeaturesService interface. In the course of developing this agent
> > though I’ve come up with a few questions, mostly related to
> > best-practices. I haven’t found answers in existing documentation; if
> > such information does exist, you have my apologies in advance for
> > troubling the mailing-list with something already answered elsewhere.
> > With that being said, here are my questions:
> >
> >
> >
> > 1.) A container has a Feature installed, “example-app”, at version
> > 1.0. Now let’s say I decide I want to run version 1.1 at some point
> > down the road. Would the best practice be to first uninstall the
> > Feature at version 1.0 and then install version 1.1, or to just
> > install version 1.1 directly (skipping the explicit uninstall step)?
> > Currently I use the FeaturesService programmatically to uninstall the
> > old version prior to install the new. While this seems to work fine,
> > I thought it wise to inquire if there was an existing best practice
> > around this or, perhaps, potential pitfalls to be avoided.
> >
> >
> >
> > 2.) The provisioning agent itself is installed as part of a Feature.
> > I currently let the agent install a new version of its encapsulating
> > Feature. With other Features not associated with the agent, as I
> > mentioned in question #1, I explicitly uninstall the old version prior
> > to installing the new. For the agent I don’t do this to prevent a
> > “bundle-suicide” type of situation. When the agent installs a new
> > version of its encapsulating Feature this triggers an implicit
> > framework restart after which the new version is installed and the
> > older version uninstalled. Interestingly enough, if I try to go the
> > other direction, say from 1.1 back to 1.0, I get unfulfilled
> > dependencies that prevent the older version of the Feature from
> > installing (and both features end up uninstalled). The dependency in
> > question (commons-lang 3.x) is actually embedded in both version 1.0
> > and 1.1 of the bundle containing the application (both bundles are
> > identical except in version number for testing). I suspect the old
> > version is attempting to import packages from the new version’s
> > bundle, but fails to do so because the latter is then invalid. Should
> > I allow my agent to install a new version of its encapsulating Feature
> > or is this going down the wrong road? Is there a best practice (or
> > any advice) around a Feature self-update scenario?
> >
> >
> > I will greatly appreciate any information/advice that can be given
> > (even “RTFM” if you can point me to the right manual).
> >
> >
> > Thanks!
> >
> > -Steve
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> Email: cibsen@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
Commiter & Project Lead
blog <http://notizblog.nierbeck.de/>
Re: Best practices around programmatic Feature manipulation (updating/self-updating)
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
You may want to take a look at Fuse Fabric
https://github.com/jboss-fuse/fuse
http://fuse.fusesource.org/fabric/
Fuse Fabric : a provisioning, configuration and management solution
for Apache Karaf, Apache ServiceMix and Fuse
Fabric has the concept of profiles that allows you to describe/define
what container(s) should be running. Then you can do rolling
upgrades/downgrades of profiles on the containers.
And you can have a git store so all the profiles is stored persistent
and you have all the power of git, so you can look in the git commit
logs for when/who did what, and versioning etc.
On the containers a Fabric Agent is running to handle the provisioning
and whatnot.
Fuse Fabric comes out of the box in JBoss Fuse -
http://www.jboss.org/products/fuse.
And you have Fabric commands in the Karaf shell, and for web UI you
have hawtio - http://hawt.io/
On Fri, Nov 15, 2013 at 5:36 PM, Steve <de...@gmail.com> wrote:
> Hello Karaf users,
>
> I’m in the process of developing a provisioning agent for a
> Karaf-based ESB (Fuse ESB/ServiceMix). Currently I’m using Features
> exclusively as my unit of deployment as opposed to working directly
> with individual bundles when provisioning. The Features mechanism is
> quite nice and has been pleasant to work with programmatically via the
> FeaturesService interface. In the course of developing this agent
> though I’ve come up with a few questions, mostly related to
> best-practices. I haven’t found answers in existing documentation; if
> such information does exist, you have my apologies in advance for
> troubling the mailing-list with something already answered elsewhere.
> With that being said, here are my questions:
>
>
>
> 1.) A container has a Feature installed, “example-app”, at version
> 1.0. Now let’s say I decide I want to run version 1.1 at some point
> down the road. Would the best practice be to first uninstall the
> Feature at version 1.0 and then install version 1.1, or to just
> install version 1.1 directly (skipping the explicit uninstall step)?
> Currently I use the FeaturesService programmatically to uninstall the
> old version prior to install the new. While this seems to work fine,
> I thought it wise to inquire if there was an existing best practice
> around this or, perhaps, potential pitfalls to be avoided.
>
>
>
> 2.) The provisioning agent itself is installed as part of a Feature.
> I currently let the agent install a new version of its encapsulating
> Feature. With other Features not associated with the agent, as I
> mentioned in question #1, I explicitly uninstall the old version prior
> to installing the new. For the agent I don’t do this to prevent a
> “bundle-suicide” type of situation. When the agent installs a new
> version of its encapsulating Feature this triggers an implicit
> framework restart after which the new version is installed and the
> older version uninstalled. Interestingly enough, if I try to go the
> other direction, say from 1.1 back to 1.0, I get unfulfilled
> dependencies that prevent the older version of the Feature from
> installing (and both features end up uninstalled). The dependency in
> question (commons-lang 3.x) is actually embedded in both version 1.0
> and 1.1 of the bundle containing the application (both bundles are
> identical except in version number for testing). I suspect the old
> version is attempting to import packages from the new version’s
> bundle, but fails to do so because the latter is then invalid. Should
> I allow my agent to install a new version of its encapsulating Feature
> or is this going down the wrong road? Is there a best practice (or
> any advice) around a Feature self-update scenario?
>
>
> I will greatly appreciate any information/advice that can be given
> (even “RTFM” if you can point me to the right manual).
>
>
> Thanks!
>
> -Steve
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: Best practices around programmatic Feature manipulation (updating/self-updating)
Posted by Steve <de...@gmail.com>.
JB,
Thank you very much for the quick reply; you definitely answered my
questions. I appreciate you taking the time to assist me in this
matter. I feel much more confident that I'm proceeding appropriately.
Best Regards,
-Steve
On Fri, Nov 15, 2013 at 12:19 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Steve,
>
> my answer inline:
>
>
>> 1.) A container has a Feature installed, “example-app”, at version
>> 1.0. Now let’s say I decide I want to run version 1.1 at some point
>> down the road. Would the best practice be to first uninstall the
>> Feature at version 1.0 and then install version 1.1, or to just
>> install version 1.1 directly (skipping the explicit uninstall step)?
>> Currently I use the FeaturesService programmatically to uninstall the
>> old version prior to install the new. While this seems to work fine,
>> I thought it wise to inquire if there was an existing best practice
>> around this or, perhaps, potential pitfalls to be avoided.
>
>
> We don't provide features:update or equivalent mechanism because it's not so
> trivial, especially for transitive features.
>
> Generally speaking, the best practice is to uninstall the "example-app"
> feature first, and install using the new feature version.
> Actually, it depends of the components shared between the two features. As I
> guess that you share most of the components, it's better to
> uninstall/install.
>
> features:update is on my TODO list.
>
>
>> 2.) The provisioning agent itself is installed as part of a Feature.
>> I currently let the agent install a new version of its encapsulating
>> Feature. With other Features not associated with the agent, as I
>> mentioned in question #1, I explicitly uninstall the old version prior
>> to installing the new. For the agent I don’t do this to prevent a
>> “bundle-suicide” type of situation. When the agent installs a new
>> version of its encapsulating Feature this triggers an implicit
>> framework restart after which the new version is installed and the
>> older version uninstalled. Interestingly enough, if I try to go the
>> other direction, say from 1.1 back to 1.0, I get unfulfilled
>> dependencies that prevent the older version of the Feature from
>> installing (and both features end up uninstalled). The dependency in
>> question (commons-lang 3.x) is actually embedded in both version 1.0
>> and 1.1 of the bundle containing the application (both bundles are
>> identical except in version number for testing). I suspect the old
>> version is attempting to import packages from the new version’s
>> bundle, but fails to do so because the latter is then invalid. Should
>> I allow my agent to install a new version of its encapsulating Feature
>> or is this going down the wrong road? Is there a best practice (or
>> any advice) around a Feature self-update scenario?
>
>
> The best way is probably to define a kind of "my-common" feature, with
> dependency="true" on their bundles (defining commons-lang, etc). Like this,
> even if you update the next agent feature, it won't change the common part
> (if I right understood ;)).
>
> Regards
> JB
>
>
>>
>>
>> I will greatly appreciate any information/advice that can be given
>> (even “RTFM” if you can point me to the right manual).
>>
>>
>> Thanks!
>>
>> -Steve
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Best practices around programmatic Feature manipulation (updating/self-updating)
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Steve,
my answer inline:
> 1.) A container has a Feature installed, “example-app”, at version
> 1.0. Now let’s say I decide I want to run version 1.1 at some point
> down the road. Would the best practice be to first uninstall the
> Feature at version 1.0 and then install version 1.1, or to just
> install version 1.1 directly (skipping the explicit uninstall step)?
> Currently I use the FeaturesService programmatically to uninstall the
> old version prior to install the new. While this seems to work fine,
> I thought it wise to inquire if there was an existing best practice
> around this or, perhaps, potential pitfalls to be avoided.
We don't provide features:update or equivalent mechanism because it's
not so trivial, especially for transitive features.
Generally speaking, the best practice is to uninstall the "example-app"
feature first, and install using the new feature version.
Actually, it depends of the components shared between the two features.
As I guess that you share most of the components, it's better to
uninstall/install.
features:update is on my TODO list.
> 2.) The provisioning agent itself is installed as part of a Feature.
> I currently let the agent install a new version of its encapsulating
> Feature. With other Features not associated with the agent, as I
> mentioned in question #1, I explicitly uninstall the old version prior
> to installing the new. For the agent I don’t do this to prevent a
> “bundle-suicide” type of situation. When the agent installs a new
> version of its encapsulating Feature this triggers an implicit
> framework restart after which the new version is installed and the
> older version uninstalled. Interestingly enough, if I try to go the
> other direction, say from 1.1 back to 1.0, I get unfulfilled
> dependencies that prevent the older version of the Feature from
> installing (and both features end up uninstalled). The dependency in
> question (commons-lang 3.x) is actually embedded in both version 1.0
> and 1.1 of the bundle containing the application (both bundles are
> identical except in version number for testing). I suspect the old
> version is attempting to import packages from the new version’s
> bundle, but fails to do so because the latter is then invalid. Should
> I allow my agent to install a new version of its encapsulating Feature
> or is this going down the wrong road? Is there a best practice (or
> any advice) around a Feature self-update scenario?
The best way is probably to define a kind of "my-common" feature, with
dependency="true" on their bundles (defining commons-lang, etc). Like
this, even if you update the next agent feature, it won't change the
common part (if I right understood ;)).
Regards
JB
>
>
> I will greatly appreciate any information/advice that can be given
> (even “RTFM” if you can point me to the right manual).
>
>
> Thanks!
>
> -Steve
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com