---------- Forwarded message ---------- From: Guillaume Nodet <[email protected]> Date: Fri, May 27, 2011 at 13:55 Subject: Re: [PROPOSAL] Features autostart attribute To: [email protected]
On Fri, May 27, 2011 at 12:54, Jean-Baptiste Onofré <[email protected]> wrote: > I think it's not exactly the same usage. > > Using your example, if I have a features descriptor like: > > <features> > <feature name="my"> > <feature>camel-core</feature> > </feature> > </features> > > 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 <repository> tag, thus not installed directly. > > 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 ? > to let the users choose the auto started features. In that case, when a new > features descriptor comes in place (by using features:addurl, dropping a KAR > or a features descriptor in the deploy folder), Karaf check if one or more > features match the features.auto.start property and install/start it. > > From a general point of view, autostart attribute could be seen as a feature > trigger as we discussed in the past :) > > Regards > JB > > On Fri 27/05/11 12:44 , Guillaume Nodet wrote:: > > 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
