Agree for the KAR: when dropping a KAR or a features descriptors into the
deploy folder, the deployer should install/start all features.
It's another enhancement at the deployer level.
On Fri 27/05/11 15:09 , Guillaume Nodet wrote::
On Fri, May 27, 2011 at 14:35, Jean-Baptiste Onofré [email protected]> wrote:
>
>
>
> I follow you Guillaume.
>
> In that case, why not just using the features.auto.start property in
> org.apache.karaf.features.cfg file and avoid the autostart attribute in the
> feature itself.
>
> Like this, the user can manage the autostart feature out of the box and for
> any feature.
Sounds good to me. Better than using flags actually.
But that still means that dropping a kar won't actually install
anything. It sounds a bit confusing to me and I'm not sure to
actually see any value in doing that. It should be similar than other
artifacts imho: when you drop something in the deploy folder, you
kinda expect it to be installed and started (bundles, wars, jbi sas,
etc...).
> WDYT ?
>
> On the other hand, as discussed in the past, I think that it could be
> interesting to have triggers in features (in before or after installation)
> where users can define any Karaf commands.
>
I fully support this idea.
> Regards
> JB
>
> On Fri 27/05/11 14:22 , Guillaume Nodet wrote::
>
> On Fri, May 27, 2011 at 14:02, Jean-Baptiste Onofré [email protected]> wrote:
>> My comments inline:
>>
>>>> if I assume that all features descriptor install and start features by
>>>> default, to be able to install "my" feature, I need to have Camel features
>>>> descriptor installed to know camel-core.
>>>> So it means that all Camel features have been installed if it's the
>>>> default behavior.
>>>>
>>>> So we have the same issue: I will have all Camel features
>>>> installed/started.
>>
>>>No because you would not drop the camel features file in the deploy
>>>folder. It would be referenced using the tag, thus not
>>>installed directly.
>>
>> You are right, but it means that we distinguish feature provided by tag or
>> features:addurl / features:install commands from the one provided by a
>> features descriptor in the deploy folder or in a KAR.
>> I'm agree that it can work, but it means that there will be impact on
>> projects. For instance, we should ask to camel to split the features
>> descriptor in several files, same in ServiceMix, etc.
>
>
> Why would you split anything ? I'm thinking if a user wants to install
> camel-core, he simply writes its own simple feature which only has a
> dependency on camel-core and drop it in the deploy folder. If he then
> want to add camel-blueprint, he just has to add one line to that xml.
>
> If we go with flags, it's written in stone and can't easily be changed
> (unless we advise users to do a big copy/paste) which is not easily
> maintainable.
>
>>
>>
>>>>
>>>> If we don't want to define the behavior on the features itself, as I said
>>>> in the Jira comment, we can image to add a property in
>>>> etc/org.apache.karaf.features.cfg file:
>>>>
>>>> features.auto.start = feature1, feature2, feature24/1.1.0
>>
>>>Isn't that the same than the boot features then ?
>>
>> The boot features are installed/started at Karaf bootstrap. The features
>> descriptors should be present in the local system repo and the URL define in
>> the org.apache.karaf.features.cfg configuration.
>> The auto.start features property defines the feature automatically
>> installed/started when a features descriptor is registered. It's not linked
>> to the Karaf bootstrap and could never be used.
>
> Ok, makes sense.
>
>>
>> Regards
>> JB
>>
>>
>>> I do understand that use case, but adding a flag is kinda abritrary
>>> and one may want some features while someone else want another set of
>>> features, so adding some flags to the camel descriptor will only
>>> benefit a few users.
>>> I think to solve that problem, one should write a simple feature
>>> descriptor with a single feature and dependencies on what they need.
>>> Then they'd just drop that one and have what they want:
>>>
>>>
>>> mvn:org.apahce.camel:....
>>>
>>> camel-blueprint
>>> ....
>>>
>>>
>>>
>>> That way, you don't drop camel features descriptor directly, but only
>>> the ones you need instead.
>>>
>>> On Fri, May 27, 2011 at 11:27, Jean-Baptiste Onofré [email protected]>
>>> wrote:
>>>> Yes, I think we should distinguish the two kinds of features.
>>>>
>>>> For instance, when adding the camel features descriptor, you have a bunch
>>>> of features.
>>>>
>>>> If it makes to have camel-core, camel-spring and camel-blueprint
>>>> automatically installed, I don't think it's the case for camel-stream,
>>>> camel-atom, etc as it depends of the user usage.
>>>>
>>>> I'm afraid that installing all features by default will install a lot of
>>>> features for nothing and Karaf will be weight for nothing (especially
>>>> regarding ServiceMix :)).
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On Fri 27/05/11 11:23 , Guillaume Nodet wrote::
>>>>
>>>> I agree. The question is does it make sense to have the features
>>>> available but not installed ? If not we could just change the
>>>> behavior without adding any flags at all.
>>>>
>>>> On Fri, May 27, 2011 at 11:18, Jean-Baptiste Onofré [email protected]>
>>>> wrote:
>>>>> Hi Guillaume,
>>>>>
>>>>> currently, if you drop a features descriptor ino the deploy folder, the
>>>>> features are present, but not installed and the bundles are not started.
>>>>>
>>>>> So the users have to install the features by hand after.
>>>>>
>>>>> More over, it's the same behavior with a KAR: no features in the KAR are
>>>>> installed/started.
>>>>>
>>>>> On the other hand, it could have sense to have features installed/started
>>>>> automatically when adding the features URL.
>>>>>
>>>>> For instance, adding the Camel features descriptor URL could
>>>>> automatically install/start camel-core, camel-spring and camel-blueprint
>>>>> features.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On Fri 27/05/11 11:08 , Guillaume Nodet wrote::
>>>>>
>>>>> What would be the effect ? installing the feature or starting the
>>>>> bundles, or both ?
>>>>> I think dropping a feature descriptor in the deploy folder should
>>>>> automatically install the feature (and start the bundles), I'm not
>>>>> sure to see what the benefit of not doing that would be.
>>>>>
>>>>> On Fri, May 27, 2011 at 10:54, Jean-Baptiste Onofré [email protected]>
>>>>> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> What do you think about adding an autostart attribute on the features
>>>>>> element ?
>>>>>>
>>>>>> The purpose is to be able to have something like:
>>>>>>
>>>>>>
>>>>>> ...
>>>>>>
>>>>>>
>>>>>> When an user register a features descriptor (using features:addurl),
>>>>>> deploy a KAR containing a features descriptor or drop a features
>>>>>> descriptor in the deploy folder, Karaf will try to automatically start
>>>>>> the features with autostart flag set to true.
>>>>>>
>>>>>> It will avoid users to:
>>>>>> - start by hand features contained in a KAR: the user can drop the KAR
>>>>>> into the deploy folder, but he must connect to Karaf and start the
>>>>>> features by hand
>>>>>> - start by hand features after an addurl when the user "controls" the
>>>>>> features content
>>>>>>
>>>>>> Thoughts ?
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/>>>>>
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/>>>>
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/>>>
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/>>
>> ------------------------
>> Open Source SOA
>> http://fusesource.com>>
>>
>>
>>
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/>
> ------------------------
> Open Source SOA
> http://fusesource.com>
>
>
>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
