You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2011/06/01 07:18:30 UTC
Re: [PROPOSAL] Features autostart attribute
Hi Christian,
Starting with the hypothesis that your features descriptor looks like:
<features>
<feature name="my" version="1.0">
<feature>camel</feature>
<feature>camel-stream</feature>
<bundle>mvn:my/my-bundle/1.0</bundle>
</feature>
<feature name="my.optional" version="1.0">
<feature>my</feature>
<bundle>mvn:my/my-optional/1.0</bundle>
</feature>
</features>
you could expect that your "my" feature will be automatically
installed/started as soon as you register the URL, but not my.optional.
The purpose of the -s option with the LDAP filter is to be able to
automatically start a set of features.
Regards
JB
On 05/31/2011 10:16 PM, Christian Schneider wrote:
> Sounds better to me than other options but I wonder if we really need
> this at all.
>
> When I deploy a camel app then I create a feature file for it with one
> feature that that references all camel features it needs. So I would
> intall the camel feature file without starting any features. Then I
> would install the feature file of my app and there all of the features
> in the file (typically only one) could be auto started. So in my
> practice I never needed to start some features. I always either wanted
> to start all or no features.
>
> Christian
>
>
> Am 31.05.2011 09:40, schrieb Jean-Baptiste Onofré:
>> Good idea Achim,
>>
>> +1 to provide -s option with LDAP filter support.
>>
>> Regards
>> JB
>>
>> On 05/31/2011 09:33 AM, Achim Nierbeck wrote:
>>> Hi JB,
>>>
>>> I understand your concern, especially with the camel features file
>>> which is the biggest I know of right now :-)
>>> Never the less I think this should be a straight forward approach and
>>> transparent for the user. So if we decide
>>> to constrain this behavior it should be done through the command.
>>> So something like
>>>
>>> features:addUrl -s (ldap filter)
>>>
>>> - to only start the features matching and
>>>
>>> features:addUrl -s
>>>
>>> - to start all features inside the features file
>>>
>>> I think this gives the user the right amount of control while doing
>>> exactly what he wants.
>>> If we think of a external file to alter, it won't be as transparent.
>
Re: [PROPOSAL] Features autostart attribute
Posted by Freeman Fang <fr...@gmail.com>.
Yep, when drop a feature.xml to deploy folder, if we can specify which
feature should get installed, that should be great.
Freeman
On 2011-10-12, at 下午5:55, Ioannis Canellos wrote:
>>
>> So, maybe, the only requirement is to install features when a
>> features
>> repository is added.
>>
>
> I was not referring to a requirement like this.
> I am mostly interested in having a way to avoid all features getting
> started
> when a feature descriptor is dropped in the deploy folder.
>
> --
> *Ioannis Canellos*
> *
> FuseSource <http://fusesource.com>
>
> **
> Blog: http://iocanel.blogspot.com
> **
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/> Committer
> Apache Gora <http://incubator.apache.org/gora/> Committer
> *
---------------------------------------------
Freeman Fang
FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Re: [PROPOSAL] Features autostart attribute
Posted by Achim Nierbeck <bc...@googlemail.com>.
wow, kind of complex just to get features running :)
just my 2 cents here ;)
2011/10/12 Daniel Kulp <dk...@apache.org>
>
> Would it make more sense to have something a bit more extensible than an
> attribute? For example, I had some bundles I wanted installed on an IBM
> JDK,
> but not on a Sun JDK. Also, JDK 7 vs 6 differences and such can also
> come
> into play. I'm kind of thinking something similar to the Maven profile
> activation element things, but make it actually work. :-) We could add
> <and> and <or> elements and such in there.
>
> Either that or define a simple DSL for the attribute
> install="${Java.Version}=7" etc....
>
>
>
> Dan
>
>
>
>
> On Wednesday, October 12, 2011 12:13:23 PM Jean-Baptiste Onofré wrote:
> > I also prefer a feature attribute.
> > Guillaume just mentioned that it means it's "built-in" the feature, and
> > don't let the user choose its behavior.
> >
> > Regarding the attribute name, install="auto" or install="manual" looks
> > good to me.
> >
> > Regards
> > JB
> >
> > On 10/12/2011 12:10 PM, Ioannis Canellos wrote:
> > > I would prefer an attribute in the feature descriptor, as it would
> > > provide more granularity for custom features.
> > > We may need to rethink the name of the attribute to avoid confusing our
> > > users.
> > >
> > > maybe call it manual="true/false" or deploy="auto/manual"
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
--
--
*Achim Nierbeck*
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Re: [PROPOSAL] Features autostart attribute
Posted by Dan Tran <da...@gmail.com>.
My apology, the requested feature already fixed at
https://issues.apache.org/jira/browse/KARAF-657
Thanks
-Dan
On Fri, Jan 6, 2012 at 6:16 PM, Dan Tran <da...@gmail.com> wrote:
> Hi
>
> where are we with auto deploy/install/start discussion?
>
> -D
>
>
>
> On Wed, Oct 12, 2011 at 8:03 AM, Ioannis Canellos <io...@gmail.com> wrote:
>> I like the idea of profiles and I can see a lot of use case for profiles. If
>> we use them exactly as maven does they will be also easier to understand.
>> However, I think that the profiles concept is a totally different story. The
>> use case here is quite simple and an approach like install="manual" would
>> fit more.
>>
>> --
>> *Ioannis Canellos*
>> *
>> FuseSource <http://fusesource.com>
>>
>> **
>> Blog: http://iocanel.blogspot.com
>> **
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> Apache ServiceMix <http://servicemix.apache.org/> Committer
>> Apache Gora <http://incubator.apache.org/gora/> Committer
>> *
Re: [PROPOSAL] Features autostart attribute
Posted by Andrei Pozolotin <an...@gmail.com>.
Hello again;
just to give a background of my use case:
motivation:
* have a dynamic configuration-driven karaf instance
* which can self-update or re-configure itself on demand
solution
* periodic pull of configuration from configuration repository on github
* link karaf auto deploy folder to the remote configuration repository
* automatic deploy/un-deploy of features.xml and package.kar per
changes in the deploy folder
Thank you,
Andrei
-------- Original Message --------
Subject: Re: [PROPOSAL] Features autostart attribute
From: Andrei Pozolotin <An...@gmail.com>
To: dev@karaf.apache.org
Date: Wed 15 Aug 2012 10:12:25 AM CDT
>
> Hello,
>
> per Achim suggestion, can I ask what is current status of this
> http://karaf.922171.n3.nabble.com/PROPOSAL-Features-autostart-attribute-td2992236.html
>
> Thank you,
>
> Andrei
>
> -------- Original Message --------
> Subject: Re: [PROPOSAL] Features autostart attribute
> From: Dan Tran <da...@gmail.com>
> To: dev@karaf.apache.org
> Date: Fri 06 Jan 2012 08:16:31 PM CST
>> Hi
>>
>> where are we with auto deploy/install/start discussion?
>>
>> -D
>>
>>
>>
>> On Wed, Oct 12, 2011 at 8:03 AM, Ioannis Canellos <io...@gmail.com> wrote:
>>> I like the idea of profiles and I can see a lot of use case for profiles. If
>>> we use them exactly as maven does they will be also easier to understand.
>>> However, I think that the profiles concept is a totally different story. The
>>> use case here is quite simple and an approach like install="manual" would
>>> fit more.
>>>
>>> --
>>> *Ioannis Canellos*
>>> *
>>> FuseSource <http://fusesource.com>
>>>
>>> **
>>> Blog: http://iocanel.blogspot.com
>>> **
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> Apache ServiceMix <http://servicemix.apache.org/> Committer
>>> Apache Gora <http://incubator.apache.org/gora/> Committer
>>> *
>
Re: [PROPOSAL] Features autostart attribute
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Andrei,
I gonna raise a Jira to track it. For now, we didn't progress on that point.
Regards
JB
On 08/15/2012 05:12 PM, Andrei Pozolotin wrote:
> Hello,
>
> per Achim suggestion, can I ask what is current status of this
> http://karaf.922171.n3.nabble.com/PROPOSAL-Features-autostart-attribute-td2992236.html
>
> Thank you,
>
> Andrei
>
> -------- Original Message --------
> Subject: Re: [PROPOSAL] Features autostart attribute
> From: Dan Tran <da...@gmail.com>
> To: dev@karaf.apache.org
> Date: Fri 06 Jan 2012 08:16:31 PM CST
>> Hi
>>
>> where are we with auto deploy/install/start discussion?
>>
>> -D
>>
>>
>>
>> On Wed, Oct 12, 2011 at 8:03 AM, Ioannis Canellos <io...@gmail.com> wrote:
>>> I like the idea of profiles and I can see a lot of use case for profiles. If
>>> we use them exactly as maven does they will be also easier to understand.
>>> However, I think that the profiles concept is a totally different story. The
>>> use case here is quite simple and an approach like install="manual" would
>>> fit more.
>>>
>>> --
>>> *Ioannis Canellos*
>>> *
>>> FuseSource <http://fusesource.com>
>>>
>>> **
>>> Blog: http://iocanel.blogspot.com
>>> **
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> Apache ServiceMix <http://servicemix.apache.org/> Committer
>>> Apache Gora <http://incubator.apache.org/gora/> Committer
>>> *
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Features autostart attribute
Posted by Andrei Pozolotin <an...@gmail.com>.
Hello,
per Achim suggestion, can I ask what is current status of this
http://karaf.922171.n3.nabble.com/PROPOSAL-Features-autostart-attribute-td2992236.html
Thank you,
Andrei
-------- Original Message --------
Subject: Re: [PROPOSAL] Features autostart attribute
From: Dan Tran <da...@gmail.com>
To: dev@karaf.apache.org
Date: Fri 06 Jan 2012 08:16:31 PM CST
> Hi
>
> where are we with auto deploy/install/start discussion?
>
> -D
>
>
>
> On Wed, Oct 12, 2011 at 8:03 AM, Ioannis Canellos <io...@gmail.com> wrote:
>> I like the idea of profiles and I can see a lot of use case for profiles. If
>> we use them exactly as maven does they will be also easier to understand.
>> However, I think that the profiles concept is a totally different story. The
>> use case here is quite simple and an approach like install="manual" would
>> fit more.
>>
>> --
>> *Ioannis Canellos*
>> *
>> FuseSource <http://fusesource.com>
>>
>> **
>> Blog: http://iocanel.blogspot.com
>> **
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> Apache ServiceMix <http://servicemix.apache.org/> Committer
>> Apache Gora <http://incubator.apache.org/gora/> Committer
>> *
Re: [PROPOSAL] Features autostart attribute
Posted by Dan Tran <da...@gmail.com>.
Hi
where are we with auto deploy/install/start discussion?
-D
On Wed, Oct 12, 2011 at 8:03 AM, Ioannis Canellos <io...@gmail.com> wrote:
> I like the idea of profiles and I can see a lot of use case for profiles. If
> we use them exactly as maven does they will be also easier to understand.
> However, I think that the profiles concept is a totally different story. The
> use case here is quite simple and an approach like install="manual" would
> fit more.
>
> --
> *Ioannis Canellos*
> *
> FuseSource <http://fusesource.com>
>
> **
> Blog: http://iocanel.blogspot.com
> **
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/> Committer
> Apache Gora <http://incubator.apache.org/gora/> Committer
> *
Re: [PROPOSAL] Features autostart attribute
Posted by Ioannis Canellos <io...@gmail.com>.
I like the idea of profiles and I can see a lot of use case for profiles. If
we use them exactly as maven does they will be also easier to understand.
However, I think that the profiles concept is a totally different story. The
use case here is quite simple and an approach like install="manual" would
fit more.
--
*Ioannis Canellos*
*
FuseSource <http://fusesource.com>
**
Blog: http://iocanel.blogspot.com
**
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
Apache Gora <http://incubator.apache.org/gora/> Committer
*
Re: [PROPOSAL] Features autostart attribute
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Achim,
you probably right :)
Regards
JB
On 10/12/2011 02:06 PM, Achim Nierbeck wrote:
> guys, what happened to KISS here?
>
> this is kinda tricky and for me it's just a bit to much :)
>
> regards, Achim
>
> 2011/10/12 Jean-Baptiste Onofré<jb...@nanthrax.net>
>
>> Hi Dan,
>>
>> in that case, we could "respin" the feature trigger concept.
>> The feature triggers allow you some Karaf scripting after a feature
>> installation.
>>
>> And we would be able to have something like:
>>
>> <feature name="xx" version="yy">
>> <bundle>...</bundle>
>> <feature version="bb">BB</feature>
>> <trigger phase="post">
>> if (${Java.Version})=7
>> feature:install xx/yy
>>
>> echo "Features Installed"
>> </trigger>
>> </feature>
>>
>> WDYT ?
>>
>> Regards
>> JB
>>
>>
>> On 10/12/2011 01:59 PM, Daniel Kulp wrote:
>>
>>>
>>> Would it make more sense to have something a bit more extensible than an
>>> attribute? For example, I had some bundles I wanted installed on an IBM
>>> JDK,
>>> but not on a Sun JDK. Also, JDK 7 vs 6 differences and such can also
>>> come
>>> into play. I'm kind of thinking something similar to the Maven profile
>>> activation element things, but make it actually work. :-) We could
>>> add
>>> <and> and<or> elements and such in there.
>>>
>>> Either that or define a simple DSL for the attribute
>>> install="${Java.Version}=7" etc....
>>>
>>>
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>> On Wednesday, October 12, 2011 12:13:23 PM Jean-Baptiste Onofré wrote:
>>>
>>>> I also prefer a feature attribute.
>>>> Guillaume just mentioned that it means it's "built-in" the feature, and
>>>> don't let the user choose its behavior.
>>>>
>>>> Regarding the attribute name, install="auto" or install="manual" looks
>>>> good to me.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 10/12/2011 12:10 PM, Ioannis Canellos wrote:
>>>>
>>>>> I would prefer an attribute in the feature descriptor, as it would
>>>>> provide more granularity for custom features.
>>>>> We may need to rethink the name of the attribute to avoid confusing our
>>>>> users.
>>>>>
>>>>> maybe call it manual="true/false" or deploy="auto/manual"
>>>>>
>>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Features autostart attribute
Posted by Achim Nierbeck <bc...@googlemail.com>.
guys, what happened to KISS here?
this is kinda tricky and for me it's just a bit to much :)
regards, Achim
2011/10/12 Jean-Baptiste Onofré <jb...@nanthrax.net>
> Hi Dan,
>
> in that case, we could "respin" the feature trigger concept.
> The feature triggers allow you some Karaf scripting after a feature
> installation.
>
> And we would be able to have something like:
>
> <feature name="xx" version="yy">
> <bundle>...</bundle>
> <feature version="bb">BB</feature>
> <trigger phase="post">
> if (${Java.Version})=7
> feature:install xx/yy
>
> echo "Features Installed"
> </trigger>
> </feature>
>
> WDYT ?
>
> Regards
> JB
>
>
> On 10/12/2011 01:59 PM, Daniel Kulp wrote:
>
>>
>> Would it make more sense to have something a bit more extensible than an
>> attribute? For example, I had some bundles I wanted installed on an IBM
>> JDK,
>> but not on a Sun JDK. Also, JDK 7 vs 6 differences and such can also
>> come
>> into play. I'm kind of thinking something similar to the Maven profile
>> activation element things, but make it actually work. :-) We could
>> add
>> <and> and<or> elements and such in there.
>>
>> Either that or define a simple DSL for the attribute
>> install="${Java.Version}=7" etc....
>>
>>
>>
>> Dan
>>
>>
>>
>>
>> On Wednesday, October 12, 2011 12:13:23 PM Jean-Baptiste Onofré wrote:
>>
>>> I also prefer a feature attribute.
>>> Guillaume just mentioned that it means it's "built-in" the feature, and
>>> don't let the user choose its behavior.
>>>
>>> Regarding the attribute name, install="auto" or install="manual" looks
>>> good to me.
>>>
>>> Regards
>>> JB
>>>
>>> On 10/12/2011 12:10 PM, Ioannis Canellos wrote:
>>>
>>>> I would prefer an attribute in the feature descriptor, as it would
>>>> provide more granularity for custom features.
>>>> We may need to rethink the name of the attribute to avoid confusing our
>>>> users.
>>>>
>>>> maybe call it manual="true/false" or deploy="auto/manual"
>>>>
>>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
--
*Achim Nierbeck*
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Re: [PROPOSAL] Features autostart attribute
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Dan,
in that case, we could "respin" the feature trigger concept.
The feature triggers allow you some Karaf scripting after a feature
installation.
And we would be able to have something like:
<feature name="xx" version="yy">
<bundle>...</bundle>
<feature version="bb">BB</feature>
<trigger phase="post">
if (${Java.Version})=7
feature:install xx/yy
echo "Features Installed"
</trigger>
</feature>
WDYT ?
Regards
JB
On 10/12/2011 01:59 PM, Daniel Kulp wrote:
>
> Would it make more sense to have something a bit more extensible than an
> attribute? For example, I had some bundles I wanted installed on an IBM JDK,
> but not on a Sun JDK. Also, JDK 7 vs 6 differences and such can also come
> into play. I'm kind of thinking something similar to the Maven profile
> activation element things, but make it actually work. :-) We could add
> <and> and<or> elements and such in there.
>
> Either that or define a simple DSL for the attribute
> install="${Java.Version}=7" etc....
>
>
>
> Dan
>
>
>
>
> On Wednesday, October 12, 2011 12:13:23 PM Jean-Baptiste Onofré wrote:
>> I also prefer a feature attribute.
>> Guillaume just mentioned that it means it's "built-in" the feature, and
>> don't let the user choose its behavior.
>>
>> Regarding the attribute name, install="auto" or install="manual" looks
>> good to me.
>>
>> Regards
>> JB
>>
>> On 10/12/2011 12:10 PM, Ioannis Canellos wrote:
>>> I would prefer an attribute in the feature descriptor, as it would
>>> provide more granularity for custom features.
>>> We may need to rethink the name of the attribute to avoid confusing our
>>> users.
>>>
>>> maybe call it manual="true/false" or deploy="auto/manual"
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Features autostart attribute
Posted by Daniel Kulp <dk...@apache.org>.
Would it make more sense to have something a bit more extensible than an
attribute? For example, I had some bundles I wanted installed on an IBM JDK,
but not on a Sun JDK. Also, JDK 7 vs 6 differences and such can also come
into play. I'm kind of thinking something similar to the Maven profile
activation element things, but make it actually work. :-) We could add
<and> and <or> elements and such in there.
Either that or define a simple DSL for the attribute
install="${Java.Version}=7" etc....
Dan
On Wednesday, October 12, 2011 12:13:23 PM Jean-Baptiste Onofré wrote:
> I also prefer a feature attribute.
> Guillaume just mentioned that it means it's "built-in" the feature, and
> don't let the user choose its behavior.
>
> Regarding the attribute name, install="auto" or install="manual" looks
> good to me.
>
> Regards
> JB
>
> On 10/12/2011 12:10 PM, Ioannis Canellos wrote:
> > I would prefer an attribute in the feature descriptor, as it would
> > provide more granularity for custom features.
> > We may need to rethink the name of the attribute to avoid confusing our
> > users.
> >
> > maybe call it manual="true/false" or deploy="auto/manual"
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: [PROPOSAL] Features autostart attribute
Posted by Andreas Pieber <an...@gmail.com>.
I'm with Achim here; Makes sense to me => +1
Kind regards,
Andreas
On Wed, Oct 12, 2011 at 12:24, Achim Nierbeck <bc...@googlemail.com>wrote:
> I like those install="auto" or install="manual" and manual being the
> default.
> So +1 from me :)
>
>
> 2011/10/12 Jean-Baptiste Onofré <jb...@nanthrax.net>
>
> > I also prefer a feature attribute.
> > Guillaume just mentioned that it means it's "built-in" the feature, and
> > don't let the user choose its behavior.
> >
> > Regarding the attribute name, install="auto" or install="manual" looks
> good
> > to me.
> >
> > Regards
> > JB
> >
> >
> > On 10/12/2011 12:10 PM, Ioannis Canellos wrote:
> >
> >> I would prefer an attribute in the feature descriptor, as it would
> provide
> >> more granularity for custom features.
> >> We may need to rethink the name of the attribute to avoid confusing our
> >> users.
> >>
> >> maybe call it manual="true/false" or deploy="auto/manual"
> >>
> >>
> >>
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
>
>
> --
> --
> *Achim Nierbeck*
>
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
>
Re: [PROPOSAL] Features autostart attribute
Posted by Achim Nierbeck <bc...@googlemail.com>.
I like those install="auto" or install="manual" and manual being the
default.
So +1 from me :)
2011/10/12 Jean-Baptiste Onofré <jb...@nanthrax.net>
> I also prefer a feature attribute.
> Guillaume just mentioned that it means it's "built-in" the feature, and
> don't let the user choose its behavior.
>
> Regarding the attribute name, install="auto" or install="manual" looks good
> to me.
>
> Regards
> JB
>
>
> On 10/12/2011 12:10 PM, Ioannis Canellos wrote:
>
>> I would prefer an attribute in the feature descriptor, as it would provide
>> more granularity for custom features.
>> We may need to rethink the name of the attribute to avoid confusing our
>> users.
>>
>> maybe call it manual="true/false" or deploy="auto/manual"
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
--
*Achim Nierbeck*
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Re: [PROPOSAL] Features autostart attribute
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I also prefer a feature attribute.
Guillaume just mentioned that it means it's "built-in" the feature, and
don't let the user choose its behavior.
Regarding the attribute name, install="auto" or install="manual" looks
good to me.
Regards
JB
On 10/12/2011 12:10 PM, Ioannis Canellos wrote:
> I would prefer an attribute in the feature descriptor, as it would provide
> more granularity for custom features.
> We may need to rethink the name of the attribute to avoid confusing our
> users.
>
> maybe call it manual="true/false" or deploy="auto/manual"
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Features autostart attribute
Posted by Ioannis Canellos <io...@gmail.com>.
I would prefer an attribute in the feature descriptor, as it would provide
more granularity for custom features.
We may need to rethink the name of the attribute to avoid confusing our
users.
maybe call it manual="true/false" or deploy="auto/manual"
--
*Ioannis Canellos*
*
FuseSource <http://fusesource.com>
**
Blog: http://iocanel.blogspot.com
**
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
Apache Gora <http://incubator.apache.org/gora/> Committer
*
Re: [PROPOSAL] Features autostart attribute
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Got it.
That's why I proposed to add an autostart="true" attribute in the
features XML, or a autostartFeatures="A B C" in the
org.apache.karaf.features.cfg file.
Regards
JB
On 10/12/2011 11:55 AM, Ioannis Canellos wrote:
>>
>> So, maybe, the only requirement is to install features when a features
>> repository is added.
>>
>
> I was not referring to a requirement like this.
> I am mostly interested in having a way to avoid all features getting started
> when a feature descriptor is dropped in the deploy folder.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Features autostart attribute
Posted by Ioannis Canellos <io...@gmail.com>.
>
> So, maybe, the only requirement is to install features when a features
> repository is added.
>
I was not referring to a requirement like this.
I am mostly interested in having a way to avoid all features getting started
when a feature descriptor is dropped in the deploy folder.
--
*Ioannis Canellos*
*
FuseSource <http://fusesource.com>
**
Blog: http://iocanel.blogspot.com
**
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
Apache Gora <http://incubator.apache.org/gora/> Committer
*
Re: [PROPOSAL] Features autostart attribute
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi guys,
FYI, I added the features autostart in the KarDeployer.
On trunk, I will start to create OSGi services for several modules: KAR,
config, wrapper, etc. The purpose is to be able to easily plug shell
commands and MBeans without code duplication.
Back to the features behavior, currently we have:
- bootFeatures that are installed by default at startup
- "KAR features" that are installed at KAR deployment
It means, that if an user performs:
features:addurl ...
no features will be installed by default, the user has to install
features by hand.
So, maybe, the only requirement is to install features when a features
repository is added.
Regards
JB
On 10/12/2011 08:39 AM, Andreas Pieber wrote:
> Well, I don't think that your use case is as uncommon as you think :-) I do
> it exactly the same way in most of my projects. Therefore the autostart for
> the deploy folder only would make perfekt sense for me.
>
> Kind regards,
> Andreas
>
> On Wed, Oct 12, 2011 at 01:29, Ioannis Canellos<io...@gmail.com> wrote:
>
>> I came across the following use case:
>>
>> I want to create a custom feature descriptor, which I will
>> be dropping inside the karaf deploy folder.
>> Currently, all features will be installed. In my case I don't want all the
>> features installed. I just want one of them installed.
>> In this case an attribute like autostart, that would be *only* used when
>> dropping features.xml in the deploy folder could make some sense.
>>
>> In my use case I need a to have a lot of features available but uninstalled
>> and have a single feature "decide" which other features need to be
>> installed.
>>
>> I know that this is not the most common use case, but having this attribute
>> (working only for the deploy folder case) won't hurt anyone.
>>
>> wdyt?
>>
>> --
>> *Ioannis Canellos*
>> *
>> FuseSource<http://fusesource.com>
>>
>> **
>> Blog: http://iocanel.blogspot.com
>> **
>> Apache Karaf<http://karaf.apache.org/> Committer& PMC
>> Apache ServiceMix<http://servicemix.apache.org/> Committer
>> Apache Gora<http://incubator.apache.org/gora/> Committer
>> *
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Features autostart attribute
Posted by Andreas Pieber <an...@gmail.com>.
Well, I don't think that your use case is as uncommon as you think :-) I do
it exactly the same way in most of my projects. Therefore the autostart for
the deploy folder only would make perfekt sense for me.
Kind regards,
Andreas
On Wed, Oct 12, 2011 at 01:29, Ioannis Canellos <io...@gmail.com> wrote:
> I came across the following use case:
>
> I want to create a custom feature descriptor, which I will
> be dropping inside the karaf deploy folder.
> Currently, all features will be installed. In my case I don't want all the
> features installed. I just want one of them installed.
> In this case an attribute like autostart, that would be *only* used when
> dropping features.xml in the deploy folder could make some sense.
>
> In my use case I need a to have a lot of features available but uninstalled
> and have a single feature "decide" which other features need to be
> installed.
>
> I know that this is not the most common use case, but having this attribute
> (working only for the deploy folder case) won't hurt anyone.
>
> wdyt?
>
> --
> *Ioannis Canellos*
> *
> FuseSource <http://fusesource.com>
>
> **
> Blog: http://iocanel.blogspot.com
> **
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/> Committer
> Apache Gora <http://incubator.apache.org/gora/> Committer
> *
>
Re: [PROPOSAL] Features autostart attribute
Posted by Ioannis Canellos <io...@gmail.com>.
I came across the following use case:
I want to create a custom feature descriptor, which I will
be dropping inside the karaf deploy folder.
Currently, all features will be installed. In my case I don't want all the
features installed. I just want one of them installed.
In this case an attribute like autostart, that would be *only* used when
dropping features.xml in the deploy folder could make some sense.
In my use case I need a to have a lot of features available but uninstalled
and have a single feature "decide" which other features need to be
installed.
I know that this is not the most common use case, but having this attribute
(working only for the deploy folder case) won't hurt anyone.
wdyt?
--
*Ioannis Canellos*
*
FuseSource <http://fusesource.com>
**
Blog: http://iocanel.blogspot.com
**
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
Apache Gora <http://incubator.apache.org/gora/> Committer
*
Re: [PROPOSAL] Features autostart attribute
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi JB,
a +1 from me, this sounds the best way.
regards, Achim
2011/6/1 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> Yes, features:install with regexp could do the stuff.
>
> But my purpose is to define a policy global to the Karaf instance: the users
> will forget to add options.
>
> So I propose:
> - add the -s option to features:addurl command, supporting LDAP filter
> - add regex support in features:install. I started to enhance the
> bundle/feature commands in that way (KARAF-325, KARAF-452)
> - add features.autostart property in etc/org.apache.karaf.features.cfg file
> to define a global policy
>
> Regarding the kar, we agreed that dropping the kar into the deploy folder
> should install/start all features contained in the Kar.
> I also propose to add a kar:install specific command to manipulate Kar
> archives (I already raised a Jira for that in the past KARAF-460).
>
> Regards
> JB
>
> On 06/01/2011 08:27 AM, Christian Schneider wrote:
>>
>> I understand what you mean. Still the same could be achieved by first
>> calling the the feature:addurl and then feature:install. The -s option
>> can be handy of course when you want to start many features at once.
>> Btw. we could alternatively support regular expressions in
>> features:install.
>>
>> How about the .kar case? You can not use an option when dropping a file
>> in the deploy dir. So I guess in this case we can only install all
>> features. Is that correct?
>>
>> Christian
>>
>>
>> Am 01.06.2011 07:18, schrieb Jean-Baptiste Onofré:
>>>
>>> Hi Christian,
>>>
>>> Starting with the hypothesis that your features descriptor looks like:
>>>
>>> <features>
>>>
>>> <feature name="my" version="1.0">
>>> <feature>camel</feature>
>>> <feature>camel-stream</feature>
>>> <bundle>mvn:my/my-bundle/1.0</bundle>
>>> </feature>
>>>
>>> <feature name="my.optional" version="1.0">
>>> <feature>my</feature>
>>> <bundle>mvn:my/my-optional/1.0</bundle>
>>> </feature>
>>>
>>> </features>
>>>
>>> you could expect that your "my" feature will be automatically
>>> installed/started as soon as you register the URL, but not my.optional.
>>>
>>> The purpose of the -s option with the LDAP filter is to be able to
>>> automatically start a set of features.
>>>
>>> Regards
>>> JB
>>>
>>> On 05/31/2011 10:16 PM, Christian Schneider wrote:
>>>>
>>>> Sounds better to me than other options but I wonder if we really need
>>>> this at all.
>>>>
>>>> When I deploy a camel app then I create a feature file for it with one
>>>> feature that that references all camel features it needs. So I would
>>>> intall the camel feature file without starting any features. Then I
>>>> would install the feature file of my app and there all of the features
>>>> in the file (typically only one) could be auto started. So in my
>>>> practice I never needed to start some features. I always either wanted
>>>> to start all or no features.
>>>>
>>>> Christian
>>>>
>>>>
>>>> Am 31.05.2011 09:40, schrieb Jean-Baptiste Onofré:
>>>>>
>>>>> Good idea Achim,
>>>>>
>>>>> +1 to provide -s option with LDAP filter support.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 05/31/2011 09:33 AM, Achim Nierbeck wrote:
>>>>>>
>>>>>> Hi JB,
>>>>>>
>>>>>> I understand your concern, especially with the camel features file
>>>>>> which is the biggest I know of right now :-)
>>>>>> Never the less I think this should be a straight forward approach and
>>>>>> transparent for the user. So if we decide
>>>>>> to constrain this behavior it should be done through the command.
>>>>>> So something like
>>>>>>
>>>>>> features:addUrl -s (ldap filter)
>>>>>>
>>>>>> - to only start the features matching and
>>>>>>
>>>>>> features:addUrl -s
>>>>>>
>>>>>> - to start all features inside the features file
>>>>>>
>>>>>> I think this gives the user the right amount of control while doing
>>>>>> exactly what he wants.
>>>>>> If we think of a external file to alter, it won't be as transparent.
>>>>
>>>
>>
>
--
--
*Achim Nierbeck*
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
Re: [PROPOSAL] Features autostart attribute
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Yes, features:install with regexp could do the stuff.
But my purpose is to define a policy global to the Karaf instance: the
users will forget to add options.
So I propose:
- add the -s option to features:addurl command, supporting LDAP filter
- add regex support in features:install. I started to enhance the
bundle/feature commands in that way (KARAF-325, KARAF-452)
- add features.autostart property in etc/org.apache.karaf.features.cfg
file to define a global policy
Regarding the kar, we agreed that dropping the kar into the deploy
folder should install/start all features contained in the Kar.
I also propose to add a kar:install specific command to manipulate Kar
archives (I already raised a Jira for that in the past KARAF-460).
Regards
JB
On 06/01/2011 08:27 AM, Christian Schneider wrote:
> I understand what you mean. Still the same could be achieved by first
> calling the the feature:addurl and then feature:install. The -s option
> can be handy of course when you want to start many features at once.
> Btw. we could alternatively support regular expressions in
> features:install.
>
> How about the .kar case? You can not use an option when dropping a file
> in the deploy dir. So I guess in this case we can only install all
> features. Is that correct?
>
> Christian
>
>
> Am 01.06.2011 07:18, schrieb Jean-Baptiste Onofré:
>> Hi Christian,
>>
>> Starting with the hypothesis that your features descriptor looks like:
>>
>> <features>
>>
>> <feature name="my" version="1.0">
>> <feature>camel</feature>
>> <feature>camel-stream</feature>
>> <bundle>mvn:my/my-bundle/1.0</bundle>
>> </feature>
>>
>> <feature name="my.optional" version="1.0">
>> <feature>my</feature>
>> <bundle>mvn:my/my-optional/1.0</bundle>
>> </feature>
>>
>> </features>
>>
>> you could expect that your "my" feature will be automatically
>> installed/started as soon as you register the URL, but not my.optional.
>>
>> The purpose of the -s option with the LDAP filter is to be able to
>> automatically start a set of features.
>>
>> Regards
>> JB
>>
>> On 05/31/2011 10:16 PM, Christian Schneider wrote:
>>> Sounds better to me than other options but I wonder if we really need
>>> this at all.
>>>
>>> When I deploy a camel app then I create a feature file for it with one
>>> feature that that references all camel features it needs. So I would
>>> intall the camel feature file without starting any features. Then I
>>> would install the feature file of my app and there all of the features
>>> in the file (typically only one) could be auto started. So in my
>>> practice I never needed to start some features. I always either wanted
>>> to start all or no features.
>>>
>>> Christian
>>>
>>>
>>> Am 31.05.2011 09:40, schrieb Jean-Baptiste Onofré:
>>>> Good idea Achim,
>>>>
>>>> +1 to provide -s option with LDAP filter support.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 05/31/2011 09:33 AM, Achim Nierbeck wrote:
>>>>> Hi JB,
>>>>>
>>>>> I understand your concern, especially with the camel features file
>>>>> which is the biggest I know of right now :-)
>>>>> Never the less I think this should be a straight forward approach and
>>>>> transparent for the user. So if we decide
>>>>> to constrain this behavior it should be done through the command.
>>>>> So something like
>>>>>
>>>>> features:addUrl -s (ldap filter)
>>>>>
>>>>> - to only start the features matching and
>>>>>
>>>>> features:addUrl -s
>>>>>
>>>>> - to start all features inside the features file
>>>>>
>>>>> I think this gives the user the right amount of control while doing
>>>>> exactly what he wants.
>>>>> If we think of a external file to alter, it won't be as transparent.
>>>
>>
>
Re: [PROPOSAL] Features autostart attribute
Posted by Christian Schneider <ch...@die-schneider.net>.
I understand what you mean. Still the same could be achieved by first
calling the the feature:addurl and then feature:install. The -s option
can be handy of course when you want to start many features at once.
Btw. we could alternatively support regular expressions in features:install.
How about the .kar case? You can not use an option when dropping a file
in the deploy dir. So I guess in this case we can only install all
features. Is that correct?
Christian
Am 01.06.2011 07:18, schrieb Jean-Baptiste Onofré:
> Hi Christian,
>
> Starting with the hypothesis that your features descriptor looks like:
>
> <features>
>
> <feature name="my" version="1.0">
> <feature>camel</feature>
> <feature>camel-stream</feature>
> <bundle>mvn:my/my-bundle/1.0</bundle>
> </feature>
>
> <feature name="my.optional" version="1.0">
> <feature>my</feature>
> <bundle>mvn:my/my-optional/1.0</bundle>
> </feature>
>
> </features>
>
> you could expect that your "my" feature will be automatically
> installed/started as soon as you register the URL, but not my.optional.
>
> The purpose of the -s option with the LDAP filter is to be able to
> automatically start a set of features.
>
> Regards
> JB
>
> On 05/31/2011 10:16 PM, Christian Schneider wrote:
>> Sounds better to me than other options but I wonder if we really need
>> this at all.
>>
>> When I deploy a camel app then I create a feature file for it with one
>> feature that that references all camel features it needs. So I would
>> intall the camel feature file without starting any features. Then I
>> would install the feature file of my app and there all of the features
>> in the file (typically only one) could be auto started. So in my
>> practice I never needed to start some features. I always either wanted
>> to start all or no features.
>>
>> Christian
>>
>>
>> Am 31.05.2011 09:40, schrieb Jean-Baptiste Onofré:
>>> Good idea Achim,
>>>
>>> +1 to provide -s option with LDAP filter support.
>>>
>>> Regards
>>> JB
>>>
>>> On 05/31/2011 09:33 AM, Achim Nierbeck wrote:
>>>> Hi JB,
>>>>
>>>> I understand your concern, especially with the camel features file
>>>> which is the biggest I know of right now :-)
>>>> Never the less I think this should be a straight forward approach and
>>>> transparent for the user. So if we decide
>>>> to constrain this behavior it should be done through the command.
>>>> So something like
>>>>
>>>> features:addUrl -s (ldap filter)
>>>>
>>>> - to only start the features matching and
>>>>
>>>> features:addUrl -s
>>>>
>>>> - to start all features inside the features file
>>>>
>>>> I think this gives the user the right amount of control while doing
>>>> exactly what he wants.
>>>> If we think of a external file to alter, it won't be as transparent.
>>
>
--
Christian Schneider
http://www.liquid-reality.de
CXF and Camel Architect