You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@karaf.apache.org by David Jencks <da...@yahoo.com> on 2011/04/19 00:48:37 UTC

Please review! Re: Why boot features?

In r1094800 I adopted these ideas.  The biggest change to review is adding a "forceStart" option to the FeaturesService options.  This is so we can assure that all bundles in boot features get started.   I thought I remembered a -s features:install option that would start all the bundles, but it doesn't seem to be there today.  If no one objects to this enum option I think we should add the command option.

In addition I made a new feature called "standard" in the standard features which contains the stuff from framework that can easily be installed as a boot feature.  I also made the full kar's feature installed as a boot feature.

The servers (old and new) seem to start OK for me and have the expected content.  Please check for problems.

thanks
david jencks

On Apr 18, 2011, at 12:15 AM, David Jencks wrote:

> I think there's a problem with boot features, and I think we don't see it with the old style assemblies because the bundles are in fact all listed in the startup.properties as well as as boot features.
> 
> There are 3 bundles in other parts of the startup.properties that depend on  Apache Karaf :: Management (3.0.0.SNAPSHOT):
> 
> [  14] [Installed  ] [            ] [   30] Apache Karaf :: Diagnostic :: Management (3.0.0.SNAPSHOT)
> [  16] [Installed  ] [            ] [   30] Apache Karaf :: Features :: Management (3.0.0.SNAPSHOT)
> [  19] [Installed  ] [            ] [   30] Apache Karaf :: Admin :: Management (3.0.0.SNAPSHOT)
> 
> Even if I put the feature core bundle at start level 25 it installs the boot feature asynchronously so the management bundle isn't installed by the time these 3 bundles need it.
> I'm not 100% sure but I think this problem still occurs if I make the feature service install the boot features synchronously.  I'm surprised but can't debug through it tonight.
> 
> One possible fix might be to move more of this into boot features so there are no dependencies from startup.properties-started-bundles on boot feature bundles.  This is a pretty big change to the structure of the minimal server.
> 
> Also the boot features don't appear to be started by default unless I put start='true' into each bundle.
> 
> Any suggestions?
> 
> thanks
> david jencks
> 
> 
> On Apr 17, 2011, at 12:23 PM, David Jencks wrote:
> 
>> Hi Guillaume,
>> 
>> I think you are suggesting:
>> 
>> 1. combine local-repo and system under a suitable name such as system or repository.  I'll use system for now.
>> 
>> 2. have as little as possible in startup.properties.  For instance the startup.properties for minimal and full servers should be the same
>> 
>> 3. everything else in the basic minimal and full servers should be started through bootFeatures.  We want to ensure that all the required bundles are in the (single) repo.
>> 
>> 4. generally to create a custom server you'll add (or maybe also remove) more bootFeatures and make sure the bundles are installed into the repo.
>> 
>> This seems entirely reasonable to me.  The only quibble I can think of at the moment is that if everything is in startup.properties you can look at one file and see everything that will be started in one place.
>> 
>> I'm not sure how it works right now, but with  this approach I think we'll want to make sure that when the features service starts it installs all the boot feature bundles immediately so the framework can use the start level specified in the features and the order listed in bootFeatures won't matter.
>> 
>> One situation this approach won't work for is if you need some bundles started before  the feature service itself.  For instance if you want jaxb 2.2 used everywhere you'd need to install the jaxb 2.2 system with a lower start level than the feature service.  So some custom servers may need to alter the startup.properties compared to the minimal server.  While in this case I expect the jaxb 2.2 feature I'll need will be in its own feature repo so it can be handled by just listing it as a compile scope dependency, so its bundles will get added to startup.properties, this kind of situation indicates to me that startupFeatures can still be useful.
>> 
>> I'll see if I run into any problems switching the new-style assemblies to this approach.
>> 
>> thanks!
>> david jencks
>> 
>> 
>> On Apr 17, 2011, at 12:00 PM, Guillaume Nodet wrote:
>> 
>>> Note that I've recently enhanced the startup mecahnism to not *always*
>>> try to install the bundles listed in the startup.properties.
>>> Previously, they were always reinstalled at startup time.
>>> 
>>> First, I don't really see the need for local-repo and system.   I
>>> think we should just merge them.
>>> 
>>> There's really no need for bootFeatures + startupFeatures.  I think we
>>> should only have one mechanism.    The original idea was that the core
>>> bundles are started with the startup.properties and everthing else
>>> installed using features, mostly through bootFeatures.   Now that we
>>> have a better maven plugin, the plugin is able to do both, but this is
>>> a bit confusing.   Note that there is some differences though:
>>> * bundles listed startup.properties have to be in the system repo as
>>> the real mvn url handlers can't be used
>>> * manually editing the statup.properties is much more tedious than
>>> changing the bootFeatures imho
>>> * you can't put bundles using wrap url handler in the startup.properties
>>> The third point is specially problematic I think.  One possible use
>>> case that isn't really addressed yet is the ability to create a
>>> configuration where some features depend on url handlers that are
>>> provisioned by other features.   Or, said another way, a feature can
>>> only be *installed* if a dependent feature is *started*.   I think
>>> moving things back in the startup.properties will make such
>>> dependencies even harder to manage.
>>> 
>>> I think I would have rathe gone the opposite direction and remove as
>>> much as possible from the startup.properties to use the bootfeatures
>>> instead, but it may be just me.
>>> 
>>> Just to understand the goal, what kind of benefit do you see by
>>> listing all bundles in the startup.properties ?  I suppose we could
>>> get rid of the features service at runtime then, but apart from that,
>>> I'm not sure to see.
>>> 
>>> On Sun, Apr 17, 2011 at 09:41, David Jencks <da...@yahoo.com> wrote:
>>>> Well, I think it may promote confusion, but there are now 3 options for features in features repositories of maven runtime scope:
>>>> 
>>>> startupFeatures.  The bundles in these features will get installed into system and listed in startup.properties
>>>> 
>>>> bootFeatures: The bundles in these features will get installed into local-repo and the feature names added to  bootFeatures in the features cfg file
>>>> 
>>>> installedFeatures: The bundles in these features will get installed into local-repo.
>>>> 
>>>> For instance,
>>>> 
>>>>              <configuration>
>>>>                  <startupFeatures>
>>>>                      <feature>ssh</feature>
>>>>                      <feature>config</feature>
>>>>                      <feature>management</feature>
>>>>                  </startupFeatures>
>>>>              </configuration>
>>>> 
>>>> Note that except for startupFeatures the bundles are installed into local-repo.  I think system should only have bundles started from startup.properties in it.
>>>> 
>>>> thoughts?
>>>> 
>>>> thanks
>>>> david jencks
>>>> 
>>>> On Apr 16, 2011, at 12:50 PM, Johan Edstrom wrote:
>>>> 
>>>>> For me it'd be the same logic as not "starting" everything from tomcats endorsed lib and
>>>>> just deploying WAR file, perhaps a little convoluted comparison, but the features additions, adding
>>>>> things and keeping "application" vs. features does make it simpler to manage as your features and deployments grow.
>>>>> 
>>>>> 
>>>>> On Apr 16, 2011, at 1:05 PM, David Jencks wrote:
>>>>> 
>>>>>> If the same bundles all get started when you start the server, what is the difference?  I think you've "designed" the server you want by including the bundles and indicating that you want them started at server startup.  How is it different whether the bundles are started from startup.properties or the feature service looking at boot features?
>>>>>> 
>>>>>> thanks
>>>>>> david jencks
>>>>>> 
>>>>>> On Apr 16, 2011, at 11:48 AM, Johan Edstrom wrote:
>>>>>> 
>>>>>>> I really think that the startup.properties is for infrastructure, bluperint etc.
>>>>>>> the startup features allows you do "design" your own distro.
>>>>>>> 
>>>>>>> 
>>>>>>> On Apr 16, 2011, at 12:42 PM, David Jencks wrote:
>>>>>>> 
>>>>>>>> Hi JB,
>>>>>>>> 
>>>>>>>> Thanks for the explanation, I think I've looked at things from only the karaf-assembly point of view too long to see anything else :-)  The way karaf-assembly works now, all the bundles in system will be listed in startup.properties and will start automatically.
>>>>>>>> 
>>>>>>>> I think you are saying:
>>>>>>>> 
>>>>>>>> -- if you include a feature in the boot feature list, you should make sure all the bundles needed are in the server already.
>>>>>>>> 
>>>>>>>> and, looking more closely at the add-features-to-repo mojo I see there's a <features> configuration element that lets you specify features to install the bundles for.
>>>>>>>> 
>>>>>>>> I'm going to add that capability to the karaf-assembly packaging.
>>>>>>>> 
>>>>>>>> There's another difference of style to resolve.  I've set up the karaf-assembly packaging so that whenever it installs a featue, it adds the feature's bundles to startup.properties at the appropriate start level.  For "boot" features this means that you don't need to list them in the features service configuration "boot features" since they will be started via the startup.properties.  On the other hand you can't uninstall this feature so easily.  Is this an important difference? Do I need to make a way to install a feature's bundles but not add the bundles to startup.properties?
>>>>>>>> 
>>>>>>>> many thanks
>>>>>>>> david jencks
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Apr 16, 2011, at 12:12 AM, Jean-Baptiste Onofré wrote:
>>>>>>>> 
>>>>>>>>> Hi David,
>>>>>>>>> 
>>>>>>>>> I'm not sure to follow you. bootFeatures property defines which features are started at Karaf bootstrap time. It allows user to start a fresh Karaf instance with a set of Karaf features loaded and installed.
>>>>>>>>> 
>>>>>>>>> For instance, in ServiceMix, we have:
>>>>>>>>> - nmr feature as boot feature and we ship all required jar (using features-add-to-repo goal) in the system OBR
>>>>>>>>> - camel-nmr, cxf-nmr, etc are part of the NMR features but not in the boot features set. As we consider this kind of features as optional, we don't ship the features jar in the system OBR
>>>>>>>>> 
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>> 
>>>>>>>>> On 04/16/2011 08:32 AM, David Jencks wrote:
>>>>>>>>>> I am wondering why we have boot features in trunk.  In particular I think there is an inconsistency around the management feature which is in the minimal boot feature list and whose jars are in the minimal server assembly.  On the other hand the ssh full boot feature doesn't have all its jars in the full server.
>>>>>>>>>> 
>>>>>>>>>> If a boot feature doesn't already have all its jars in the server, won't this require internet access on initial startup?
>>>>>>>>>> 
>>>>>>>>>> If all the jars for a boot feature are already installed in the server, why call it a boot feature, why not just start it with the rest of the jars?  For this question I may be biased by looking at the packaging based assemblies where the startup.properties is constructed from the features that are installed into the server, so it is at least as east to configure the assembly to just include the jars as to configure a boot feature.
>>>>>>>>>> 
>>>>>>>>>> Am I missing something?
>>>>>>>>>> 
>>>>>>>>>> thanks
>>>>>>>>>> david jencks
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>> 
>>> Connect at CamelOne May 24-26
>>> The Open Source Integration Conference
>>> http://camelone.com/
>> 
>

Re: Please review! Re: Why boot features?

Posted by Achim Nierbeck <bc...@googlemail.com>.

Thanks David will look into this later this night :)

regards, Achim

2011/4/20 David Jencks <da...@yahoo.com>:
> Achim sent me his framework directory privately at which point I discovered that git had not checked in the bin directories in framework and full.  I found that my local copies still had .svn files in them... does that confuse git into thinking the directories don't exist?  Even after I removed the .svn files git didn't notice them....
>
> I added the files by hand to my svn checkout and checked them in so they should be available now.  When I tried git svn rebase it finally noticed the files and said
>
> error: The following untracked working tree files would be overwritten by checkout:
> <the files it didn't notice previously or indeed after the rebase attempt>
>
> I guess git is not entirely bug free.
>
> Anyway maybe others will be able to build new-style server assemblies now.
>
> thanks
> david jencks
>
> On Apr 19, 2011, at 12:36 PM, David Jencks wrote:
>
>> Hi Achim,
>>
>> I looked over the kar archiving code and didn't see anything mac or osx specific so I think I'm going to need some help investigating what's going on on other systems.  Maybe if you or someone could zip up the target folder of the framework kar and send it to me I could try and think of a clue of what is going wrong....
>>
>> thanks
>> david jencks
>>
>> On Apr 19, 2011, at 11:53 AM, Achim Nierbeck wrote:
>>
>>> Hi David,
>>>
>>> thanks for fixing :)
>>>
>>> I'm partially trying to get 2.2.1 going, that's probably why 3.0
>>> doesn't get a good testing :)
>>> By the way of testing, last time I looked into the kar produced
>>> artifacts, the bin folder wasn't still included.
>>>
>>> regards, Achim
>>>
>>> 2011/4/19 David Jencks <da...@yahoo.com>:
>>>> I looked into this more and found that I'd made the default start value false rather than true in the jaxb model.  I added some comments to the schema copes and fixed this, now features appear to start automatically when installed.
>>>>
>>>> This problem didn't have anything to do with boot features.... which indicates to me that trunk is not getting any significant testing..... not a good sign if we want to release it soon.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Apr 19, 2011, at 4:32 AM, Christian Schneider wrote:
>>>>
>>>>> +1
>>>>> For auto starting features by default
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> Am 19.04.2011 09:05, schrieb Achim Nierbeck:
>>>>>> hm,
>>>>>>
>>>>>> I only have one open question, the other "standard" features like war
>>>>>> and webconsole, when I install those features the bundles stay in
>>>>>> installed state, and some
>>>>>> of those bundles are supposed to be system bundles, e.g. the web
>>>>>> console bundle. I kind of miss the standard behaviour of installing a
>>>>>> feature and all bundles are up and running. How do we get around that?
>>>>>> And actually the current behavior of installing a feature and those
>>>>>> features are right available is one of the best things about the
>>>>>> features. I'd rather like to see it the other way round.
>>>>>>
>>>>>> Default behavior should be the same as before, if a feature is
>>>>>> installed all bundles are started right away, if I don't want it that
>>>>>> way I need to add a special flag like --nostart or something.
>>>>>>
>>>>>> regards, Achim
>>>>>>
>>>>>> 2011/4/19 David Jencks<da...@yahoo.com>:
>>>>>>> In r1094800 I adopted these ideas.  The biggest change to review is adding a "forceStart" option to the FeaturesService options.  This is so we can assure that all bundles in boot features get started.   I thought I remembered a -s features:install option that would start all the bundles, but it doesn't seem to be there today.  If no one objects to this enum option I think we should add the command option.
>>>>>>>
>>>>>>> In addition I made a new feature called "standard" in the standard features which contains the stuff from framework that can easily be installed as a boot feature.  I also made the full kar's feature installed as a boot feature.
>>>>>>>
>>>>>>> The servers (old and new) seem to start OK for me and have the expected content.  Please check for problems.
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>> On Apr 18, 2011, at 12:15 AM, David Jencks wrote:
>>>>>>>
>>>>>>>> I think there's a problem with boot features, and I think we don't see it with the old style assemblies because the bundles are in fact all listed in the startup.properties as well as as boot features.
>>>>>>>>
>>>>>>>> There are 3 bundles in other parts of the startup.properties that depend on  Apache Karaf :: Management (3.0.0.SNAPSHOT):
>>>>>>>>
>>>>>>>> [  14] [Installed  ] [            ] [   30] Apache Karaf :: Diagnostic :: Management (3.0.0.SNAPSHOT)
>>>>>>>> [  16] [Installed  ] [            ] [   30] Apache Karaf :: Features :: Management (3.0.0.SNAPSHOT)
>>>>>>>> [  19] [Installed  ] [            ] [   30] Apache Karaf :: Admin :: Management (3.0.0.SNAPSHOT)
>>>>>>>>
>>>>>>>> Even if I put the feature core bundle at start level 25 it installs the boot feature asynchronously so the management bundle isn't installed by the time these 3 bundles need it.
>>>>>>>> I'm not 100% sure but I think this problem still occurs if I make the feature service install the boot features synchronously.  I'm surprised but can't debug through it tonight.
>>>>>>>>
>>>>>>>> One possible fix might be to move more of this into boot features so there are no dependencies from startup.properties-started-bundles on boot feature bundles.  This is a pretty big change to the structure of the minimal server.
>>>>>>>>
>>>>>>>> Also the boot features don't appear to be started by default unless I put start='true' into each bundle.
>>>>>>>>
>>>>>>>> Any suggestions?
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>>
>>>>>>>> On Apr 17, 2011, at 12:23 PM, David Jencks wrote:
>>>>>>>>
>>>>>>>>> Hi Guillaume,
>>>>>>>>>
>>>>>>>>> I think you are suggesting:
>>>>>>>>>
>>>>>>>>> 1. combine local-repo and system under a suitable name such as system or repository.  I'll use system for now.
>>>>>>>>>
>>>>>>>>> 2. have as little as possible in startup.properties.  For instance the startup.properties for minimal and full servers should be the same
>>>>>>>>>
>>>>>>>>> 3. everything else in the basic minimal and full servers should be started through bootFeatures.  We want to ensure that all the required bundles are in the (single) repo.
>>>>>>>>>
>>>>>>>>> 4. generally to create a custom server you'll add (or maybe also remove) more bootFeatures and make sure the bundles are installed into the repo.
>>>>>>>>>
>>>>>>>>> This seems entirely reasonable to me.  The only quibble I can think of at the moment is that if everything is in startup.properties you can look at one file and see everything that will be started in one place.
>>>>>>>>>
>>>>>>>>> I'm not sure how it works right now, but with  this approach I think we'll want to make sure that when the features service starts it installs all the boot feature bundles immediately so the framework can use the start level specified in the features and the order listed in bootFeatures won't matter.
>>>>>>>>>
>>>>>>>>> One situation this approach won't work for is if you need some bundles started before  the feature service itself.  For instance if you want jaxb 2.2 used everywhere you'd need to install the jaxb 2.2 system with a lower start level than the feature service.  So some custom servers may need to alter the startup.properties compared to the minimal server.  While in this case I expect the jaxb 2.2 feature I'll need will be in its own feature repo so it can be handled by just listing it as a compile scope dependency, so its bundles will get added to startup.properties, this kind of situation indicates to me that startupFeatures can still be useful.
>>>>>>>>>
>>>>>>>>> I'll see if I run into any problems switching the new-style assemblies to this approach.
>>>>>>>>>
>>>>>>>>> thanks!
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Apr 17, 2011, at 12:00 PM, Guillaume Nodet wrote:
>>>>>>>>>
>>>>>>>>>> Note that I've recently enhanced the startup mecahnism to not *always*
>>>>>>>>>> try to install the bundles listed in the startup.properties.
>>>>>>>>>> Previously, they were always reinstalled at startup time.
>>>>>>>>>>
>>>>>>>>>> First, I don't really see the need for local-repo and system.   I
>>>>>>>>>> think we should just merge them.
>>>>>>>>>>
>>>>>>>>>> There's really no need for bootFeatures + startupFeatures.  I think we
>>>>>>>>>> should only have one mechanism.    The original idea was that the core
>>>>>>>>>> bundles are started with the startup.properties and everthing else
>>>>>>>>>> installed using features, mostly through bootFeatures.   Now that we
>>>>>>>>>> have a better maven plugin, the plugin is able to do both, but this is
>>>>>>>>>> a bit confusing.   Note that there is some differences though:
>>>>>>>>>> * bundles listed startup.properties have to be in the system repo as
>>>>>>>>>> the real mvn url handlers can't be used
>>>>>>>>>> * manually editing the statup.properties is much more tedious than
>>>>>>>>>> changing the bootFeatures imho
>>>>>>>>>> * you can't put bundles using wrap url handler in the startup.properties
>>>>>>>>>> The third point is specially problematic I think.  One possible use
>>>>>>>>>> case that isn't really addressed yet is the ability to create a
>>>>>>>>>> configuration where some features depend on url handlers that are
>>>>>>>>>> provisioned by other features.   Or, said another way, a feature can
>>>>>>>>>> only be *installed* if a dependent feature is *started*.   I think
>>>>>>>>>> moving things back in the startup.properties will make such
>>>>>>>>>> dependencies even harder to manage.
>>>>>>>>>>
>>>>>>>>>> I think I would have rathe gone the opposite direction and remove as
>>>>>>>>>> much as possible from the startup.properties to use the bootfeatures
>>>>>>>>>> instead, but it may be just me.
>>>>>>>>>>
>>>>>>>>>> Just to understand the goal, what kind of benefit do you see by
>>>>>>>>>> listing all bundles in the startup.properties ?  I suppose we could
>>>>>>>>>> get rid of the features service at runtime then, but apart from that,
>>>>>>>>>> I'm not sure to see.
>>>>>>>>>>
>>>>>>>>>> On Sun, Apr 17, 2011 at 09:41, David Jencks<da...@yahoo.com>  wrote:
>>>>>>>>>>> Well, I think it may promote confusion, but there are now 3 options for features in features repositories of maven runtime scope:
>>>>>>>>>>>
>>>>>>>>>>> startupFeatures.  The bundles in these features will get installed into system and listed in startup.properties
>>>>>>>>>>>
>>>>>>>>>>> bootFeatures: The bundles in these features will get installed into local-repo and the feature names added to  bootFeatures in the features cfg file
>>>>>>>>>>>
>>>>>>>>>>> installedFeatures: The bundles in these features will get installed into local-repo.
>>>>>>>>>>>
>>>>>>>>>>> For instance,
>>>>>>>>>>>
>>>>>>>>>>>             <configuration>
>>>>>>>>>>>                 <startupFeatures>
>>>>>>>>>>>                     <feature>ssh</feature>
>>>>>>>>>>>                     <feature>config</feature>
>>>>>>>>>>>                     <feature>management</feature>
>>>>>>>>>>>                 </startupFeatures>
>>>>>>>>>>>             </configuration>
>>>>>>>>>>>
>>>>>>>>>>> Note that except for startupFeatures the bundles are installed into local-repo.  I think system should only have bundles started from startup.properties in it.
>>>>>>>>>>>
>>>>>>>>>>> thoughts?
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>> On Apr 16, 2011, at 12:50 PM, Johan Edstrom wrote:
>>>>>>>>>>>
>>>>>>>>>>>> For me it'd be the same logic as not "starting" everything from tomcats endorsed lib and
>>>>>>>>>>>> just deploying WAR file, perhaps a little convoluted comparison, but the features additions, adding
>>>>>>>>>>>> things and keeping "application" vs. features does make it simpler to manage as your features and deployments grow.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Apr 16, 2011, at 1:05 PM, David Jencks wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> If the same bundles all get started when you start the server, what is the difference?  I think you've "designed" the server you want by including the bundles and indicating that you want them started at server startup.  How is it different whether the bundles are started from startup.properties or the feature service looking at boot features?
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Apr 16, 2011, at 11:48 AM, Johan Edstrom wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I really think that the startup.properties is for infrastructure, bluperint etc.
>>>>>>>>>>>>>> the startup features allows you do "design" your own distro.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Apr 16, 2011, at 12:42 PM, David Jencks wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi JB,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks for the explanation, I think I've looked at things from only the karaf-assembly point of view too long to see anything else :-)  The way karaf-assembly works now, all the bundles in system will be listed in startup.properties and will start automatically.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think you are saying:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- if you include a feature in the boot feature list, you should make sure all the bundles needed are in the server already.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> and, looking more closely at the add-features-to-repo mojo I see there's a<features>  configuration element that lets you specify features to install the bundles for.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm going to add that capability to the karaf-assembly packaging.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There's another difference of style to resolve.  I've set up the karaf-assembly packaging so that whenever it installs a featue, it adds the feature's bundles to startup.properties at the appropriate start level.  For "boot" features this means that you don't need to list them in the features service configuration "boot features" since they will be started via the startup.properties.  On the other hand you can't uninstall this feature so easily.  Is this an important difference? Do I need to make a way to install a feature's bundles but not add the bundles to startup.properties?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> many thanks
>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Apr 16, 2011, at 12:12 AM, Jean-Baptiste Onofré wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm not sure to follow you. bootFeatures property defines which features are started at Karaf bootstrap time. It allows user to start a fresh Karaf instance with a set of Karaf features loaded and installed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For instance, in ServiceMix, we have:
>>>>>>>>>>>>>>>> - nmr feature as boot feature and we ship all required jar (using features-add-to-repo goal) in the system OBR
>>>>>>>>>>>>>>>> - camel-nmr, cxf-nmr, etc are part of the NMR features but not in the boot features set. As we consider this kind of features as optional, we don't ship the features jar in the system OBR
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>> JB
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 04/16/2011 08:32 AM, David Jencks wrote:
>>>>>>>>>>>>>>>>> I am wondering why we have boot features in trunk.  In particular I think there is an inconsistency around the management feature which is in the minimal boot feature list and whose jars are in the minimal server assembly.  On the other hand the ssh full boot feature doesn't have all its jars in the full server.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If a boot feature doesn't already have all its jars in the server, won't this require internet access on initial startup?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If all the jars for a boot feature are already installed in the server, why call it a boot feature, why not just start it with the rest of the jars?  For this question I may be biased by looking at the packaging based assemblies where the startup.properties is constructed from the features that are installed into the server, so it is at least as east to configure the assembly to just include the jars as to configure a boot feature.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Am I missing something?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Cheers,
>>>>>>>>>> Guillaume Nodet
>>>>>>>>>> ------------------------
>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>> ------------------------
>>>>>>>>>> Open Source SOA
>>>>>>>>>> http://fusesource.com
>>>>>>>>>>
>>>>>>>>>> Connect at CamelOne May 24-26
>>>>>>>>>> The Open Source Integration Conference
>>>>>>>>>> http://camelone.com/
>>>>>>>
>>>>>
>>>>> --
>>>>> Christian Schneider
>>>>> CXF and Camel Architect
>>>>> SOPERA - The Application Integration Division of Talend
>>>>> http://www.talend.com
>>>>>
>>>>
>>>>
>>
>
>

Re: Please review! Re: Why boot features?

Posted by David Jencks <da...@yahoo.com>.

Achim sent me his framework directory privately at which point I discovered that git had not checked in the bin directories in framework and full.  I found that my local copies still had .svn files in them... does that confuse git into thinking the directories don't exist?  Even after I removed the .svn files git didn't notice them....

I added the files by hand to my svn checkout and checked them in so they should be available now.  When I tried git svn rebase it finally noticed the files and said 

error: The following untracked working tree files would be overwritten by checkout:
<the files it didn't notice previously or indeed after the rebase attempt>

I guess git is not entirely bug free.

Anyway maybe others will be able to build new-style server assemblies now.

thanks
david jencks

On Apr 19, 2011, at 12:36 PM, David Jencks wrote:

> Hi Achim,
> 
> I looked over the kar archiving code and didn't see anything mac or osx specific so I think I'm going to need some help investigating what's going on on other systems.  Maybe if you or someone could zip up the target folder of the framework kar and send it to me I could try and think of a clue of what is going wrong....
> 
> thanks
> david jencks
> 
> On Apr 19, 2011, at 11:53 AM, Achim Nierbeck wrote:
> 
>> Hi David,
>> 
>> thanks for fixing :)
>> 
>> I'm partially trying to get 2.2.1 going, that's probably why 3.0
>> doesn't get a good testing :)
>> By the way of testing, last time I looked into the kar produced
>> artifacts, the bin folder wasn't still included.
>> 
>> regards, Achim
>> 
>> 2011/4/19 David Jencks <da...@yahoo.com>:
>>> I looked into this more and found that I'd made the default start value false rather than true in the jaxb model.  I added some comments to the schema copes and fixed this, now features appear to start automatically when installed.
>>> 
>>> This problem didn't have anything to do with boot features.... which indicates to me that trunk is not getting any significant testing..... not a good sign if we want to release it soon.
>>> 
>>> thanks
>>> david jencks
>>> 
>>> On Apr 19, 2011, at 4:32 AM, Christian Schneider wrote:
>>> 
>>>> +1
>>>> For auto starting features by default
>>>> 
>>>> Christian
>>>> 
>>>> 
>>>> Am 19.04.2011 09:05, schrieb Achim Nierbeck:
>>>>> hm,
>>>>> 
>>>>> I only have one open question, the other "standard" features like war
>>>>> and webconsole, when I install those features the bundles stay in
>>>>> installed state, and some
>>>>> of those bundles are supposed to be system bundles, e.g. the web
>>>>> console bundle. I kind of miss the standard behaviour of installing a
>>>>> feature and all bundles are up and running. How do we get around that?
>>>>> And actually the current behavior of installing a feature and those
>>>>> features are right available is one of the best things about the
>>>>> features. I'd rather like to see it the other way round.
>>>>> 
>>>>> Default behavior should be the same as before, if a feature is
>>>>> installed all bundles are started right away, if I don't want it that
>>>>> way I need to add a special flag like --nostart or something.
>>>>> 
>>>>> regards, Achim
>>>>> 
>>>>> 2011/4/19 David Jencks<da...@yahoo.com>:
>>>>>> In r1094800 I adopted these ideas.  The biggest change to review is adding a "forceStart" option to the FeaturesService options.  This is so we can assure that all bundles in boot features get started.   I thought I remembered a -s features:install option that would start all the bundles, but it doesn't seem to be there today.  If no one objects to this enum option I think we should add the command option.
>>>>>> 
>>>>>> In addition I made a new feature called "standard" in the standard features which contains the stuff from framework that can easily be installed as a boot feature.  I also made the full kar's feature installed as a boot feature.
>>>>>> 
>>>>>> The servers (old and new) seem to start OK for me and have the expected content.  Please check for problems.
>>>>>> 
>>>>>> thanks
>>>>>> david jencks
>>>>>> 
>>>>>> On Apr 18, 2011, at 12:15 AM, David Jencks wrote:
>>>>>> 
>>>>>>> I think there's a problem with boot features, and I think we don't see it with the old style assemblies because the bundles are in fact all listed in the startup.properties as well as as boot features.
>>>>>>> 
>>>>>>> There are 3 bundles in other parts of the startup.properties that depend on  Apache Karaf :: Management (3.0.0.SNAPSHOT):
>>>>>>> 
>>>>>>> [  14] [Installed  ] [            ] [   30] Apache Karaf :: Diagnostic :: Management (3.0.0.SNAPSHOT)
>>>>>>> [  16] [Installed  ] [            ] [   30] Apache Karaf :: Features :: Management (3.0.0.SNAPSHOT)
>>>>>>> [  19] [Installed  ] [            ] [   30] Apache Karaf :: Admin :: Management (3.0.0.SNAPSHOT)
>>>>>>> 
>>>>>>> Even if I put the feature core bundle at start level 25 it installs the boot feature asynchronously so the management bundle isn't installed by the time these 3 bundles need it.
>>>>>>> I'm not 100% sure but I think this problem still occurs if I make the feature service install the boot features synchronously.  I'm surprised but can't debug through it tonight.
>>>>>>> 
>>>>>>> One possible fix might be to move more of this into boot features so there are no dependencies from startup.properties-started-bundles on boot feature bundles.  This is a pretty big change to the structure of the minimal server.
>>>>>>> 
>>>>>>> Also the boot features don't appear to be started by default unless I put start='true' into each bundle.
>>>>>>> 
>>>>>>> Any suggestions?
>>>>>>> 
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>> 
>>>>>>> 
>>>>>>> On Apr 17, 2011, at 12:23 PM, David Jencks wrote:
>>>>>>> 
>>>>>>>> Hi Guillaume,
>>>>>>>> 
>>>>>>>> I think you are suggesting:
>>>>>>>> 
>>>>>>>> 1. combine local-repo and system under a suitable name such as system or repository.  I'll use system for now.
>>>>>>>> 
>>>>>>>> 2. have as little as possible in startup.properties.  For instance the startup.properties for minimal and full servers should be the same
>>>>>>>> 
>>>>>>>> 3. everything else in the basic minimal and full servers should be started through bootFeatures.  We want to ensure that all the required bundles are in the (single) repo.
>>>>>>>> 
>>>>>>>> 4. generally to create a custom server you'll add (or maybe also remove) more bootFeatures and make sure the bundles are installed into the repo.
>>>>>>>> 
>>>>>>>> This seems entirely reasonable to me.  The only quibble I can think of at the moment is that if everything is in startup.properties you can look at one file and see everything that will be started in one place.
>>>>>>>> 
>>>>>>>> I'm not sure how it works right now, but with  this approach I think we'll want to make sure that when the features service starts it installs all the boot feature bundles immediately so the framework can use the start level specified in the features and the order listed in bootFeatures won't matter.
>>>>>>>> 
>>>>>>>> One situation this approach won't work for is if you need some bundles started before  the feature service itself.  For instance if you want jaxb 2.2 used everywhere you'd need to install the jaxb 2.2 system with a lower start level than the feature service.  So some custom servers may need to alter the startup.properties compared to the minimal server.  While in this case I expect the jaxb 2.2 feature I'll need will be in its own feature repo so it can be handled by just listing it as a compile scope dependency, so its bundles will get added to startup.properties, this kind of situation indicates to me that startupFeatures can still be useful.
>>>>>>>> 
>>>>>>>> I'll see if I run into any problems switching the new-style assemblies to this approach.
>>>>>>>> 
>>>>>>>> thanks!
>>>>>>>> david jencks
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Apr 17, 2011, at 12:00 PM, Guillaume Nodet wrote:
>>>>>>>> 
>>>>>>>>> Note that I've recently enhanced the startup mecahnism to not *always*
>>>>>>>>> try to install the bundles listed in the startup.properties.
>>>>>>>>> Previously, they were always reinstalled at startup time.
>>>>>>>>> 
>>>>>>>>> First, I don't really see the need for local-repo and system.   I
>>>>>>>>> think we should just merge them.
>>>>>>>>> 
>>>>>>>>> There's really no need for bootFeatures + startupFeatures.  I think we
>>>>>>>>> should only have one mechanism.    The original idea was that the core
>>>>>>>>> bundles are started with the startup.properties and everthing else
>>>>>>>>> installed using features, mostly through bootFeatures.   Now that we
>>>>>>>>> have a better maven plugin, the plugin is able to do both, but this is
>>>>>>>>> a bit confusing.   Note that there is some differences though:
>>>>>>>>> * bundles listed startup.properties have to be in the system repo as
>>>>>>>>> the real mvn url handlers can't be used
>>>>>>>>> * manually editing the statup.properties is much more tedious than
>>>>>>>>> changing the bootFeatures imho
>>>>>>>>> * you can't put bundles using wrap url handler in the startup.properties
>>>>>>>>> The third point is specially problematic I think.  One possible use
>>>>>>>>> case that isn't really addressed yet is the ability to create a
>>>>>>>>> configuration where some features depend on url handlers that are
>>>>>>>>> provisioned by other features.   Or, said another way, a feature can
>>>>>>>>> only be *installed* if a dependent feature is *started*.   I think
>>>>>>>>> moving things back in the startup.properties will make such
>>>>>>>>> dependencies even harder to manage.
>>>>>>>>> 
>>>>>>>>> I think I would have rathe gone the opposite direction and remove as
>>>>>>>>> much as possible from the startup.properties to use the bootfeatures
>>>>>>>>> instead, but it may be just me.
>>>>>>>>> 
>>>>>>>>> Just to understand the goal, what kind of benefit do you see by
>>>>>>>>> listing all bundles in the startup.properties ?  I suppose we could
>>>>>>>>> get rid of the features service at runtime then, but apart from that,
>>>>>>>>> I'm not sure to see.
>>>>>>>>> 
>>>>>>>>> On Sun, Apr 17, 2011 at 09:41, David Jencks<da...@yahoo.com>  wrote:
>>>>>>>>>> Well, I think it may promote confusion, but there are now 3 options for features in features repositories of maven runtime scope:
>>>>>>>>>> 
>>>>>>>>>> startupFeatures.  The bundles in these features will get installed into system and listed in startup.properties
>>>>>>>>>> 
>>>>>>>>>> bootFeatures: The bundles in these features will get installed into local-repo and the feature names added to  bootFeatures in the features cfg file
>>>>>>>>>> 
>>>>>>>>>> installedFeatures: The bundles in these features will get installed into local-repo.
>>>>>>>>>> 
>>>>>>>>>> For instance,
>>>>>>>>>> 
>>>>>>>>>>             <configuration>
>>>>>>>>>>                 <startupFeatures>
>>>>>>>>>>                     <feature>ssh</feature>
>>>>>>>>>>                     <feature>config</feature>
>>>>>>>>>>                     <feature>management</feature>
>>>>>>>>>>                 </startupFeatures>
>>>>>>>>>>             </configuration>
>>>>>>>>>> 
>>>>>>>>>> Note that except for startupFeatures the bundles are installed into local-repo.  I think system should only have bundles started from startup.properties in it.
>>>>>>>>>> 
>>>>>>>>>> thoughts?
>>>>>>>>>> 
>>>>>>>>>> thanks
>>>>>>>>>> david jencks
>>>>>>>>>> 
>>>>>>>>>> On Apr 16, 2011, at 12:50 PM, Johan Edstrom wrote:
>>>>>>>>>> 
>>>>>>>>>>> For me it'd be the same logic as not "starting" everything from tomcats endorsed lib and
>>>>>>>>>>> just deploying WAR file, perhaps a little convoluted comparison, but the features additions, adding
>>>>>>>>>>> things and keeping "application" vs. features does make it simpler to manage as your features and deployments grow.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Apr 16, 2011, at 1:05 PM, David Jencks wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> If the same bundles all get started when you start the server, what is the difference?  I think you've "designed" the server you want by including the bundles and indicating that you want them started at server startup.  How is it different whether the bundles are started from startup.properties or the feature service looking at boot features?
>>>>>>>>>>>> 
>>>>>>>>>>>> thanks
>>>>>>>>>>>> david jencks
>>>>>>>>>>>> 
>>>>>>>>>>>> On Apr 16, 2011, at 11:48 AM, Johan Edstrom wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> I really think that the startup.properties is for infrastructure, bluperint etc.
>>>>>>>>>>>>> the startup features allows you do "design" your own distro.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Apr 16, 2011, at 12:42 PM, David Jencks wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi JB,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks for the explanation, I think I've looked at things from only the karaf-assembly point of view too long to see anything else :-)  The way karaf-assembly works now, all the bundles in system will be listed in startup.properties and will start automatically.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I think you are saying:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> -- if you include a feature in the boot feature list, you should make sure all the bundles needed are in the server already.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> and, looking more closely at the add-features-to-repo mojo I see there's a<features>  configuration element that lets you specify features to install the bundles for.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I'm going to add that capability to the karaf-assembly packaging.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> There's another difference of style to resolve.  I've set up the karaf-assembly packaging so that whenever it installs a featue, it adds the feature's bundles to startup.properties at the appropriate start level.  For "boot" features this means that you don't need to list them in the features service configuration "boot features" since they will be started via the startup.properties.  On the other hand you can't uninstall this feature so easily.  Is this an important difference? Do I need to make a way to install a feature's bundles but not add the bundles to startup.properties?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> many thanks
>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Apr 16, 2011, at 12:12 AM, Jean-Baptiste Onofré wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I'm not sure to follow you. bootFeatures property defines which features are started at Karaf bootstrap time. It allows user to start a fresh Karaf instance with a set of Karaf features loaded and installed.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> For instance, in ServiceMix, we have:
>>>>>>>>>>>>>>> - nmr feature as boot feature and we ship all required jar (using features-add-to-repo goal) in the system OBR
>>>>>>>>>>>>>>> - camel-nmr, cxf-nmr, etc are part of the NMR features but not in the boot features set. As we consider this kind of features as optional, we don't ship the features jar in the system OBR
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>> JB
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 04/16/2011 08:32 AM, David Jencks wrote:
>>>>>>>>>>>>>>>> I am wondering why we have boot features in trunk.  In particular I think there is an inconsistency around the management feature which is in the minimal boot feature list and whose jars are in the minimal server assembly.  On the other hand the ssh full boot feature doesn't have all its jars in the full server.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> If a boot feature doesn't already have all its jars in the server, won't this require internet access on initial startup?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> If all the jars for a boot feature are already installed in the server, why call it a boot feature, why not just start it with the rest of the jars?  For this question I may be biased by looking at the packaging based assemblies where the startup.properties is constructed from the features that are installed into the server, so it is at least as east to configure the assembly to just include the jars as to configure a boot feature.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Am I missing something?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Cheers,
>>>>>>>>> Guillaume Nodet
>>>>>>>>> ------------------------
>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>> ------------------------
>>>>>>>>> Open Source SOA
>>>>>>>>> http://fusesource.com
>>>>>>>>> 
>>>>>>>>> Connect at CamelOne May 24-26
>>>>>>>>> The Open Source Integration Conference
>>>>>>>>> http://camelone.com/
>>>>>> 
>>>> 
>>>> --
>>>> Christian Schneider
>>>> CXF and Camel Architect
>>>> SOPERA - The Application Integration Division of Talend
>>>> http://www.talend.com
>>>> 
>>> 
>>> 
>

Re: Please review! Re: Why boot features?

Posted by David Jencks <da...@yahoo.com>.

Hi Achim,

I looked over the kar archiving code and didn't see anything mac or osx specific so I think I'm going to need some help investigating what's going on on other systems.  Maybe if you or someone could zip up the target folder of the framework kar and send it to me I could try and think of a clue of what is going wrong....

thanks
david jencks

On Apr 19, 2011, at 11:53 AM, Achim Nierbeck wrote:

> Hi David,
> 
> thanks for fixing :)
> 
> I'm partially trying to get 2.2.1 going, that's probably why 3.0
> doesn't get a good testing :)
> By the way of testing, last time I looked into the kar produced
> artifacts, the bin folder wasn't still included.
> 
> regards, Achim
> 
> 2011/4/19 David Jencks <da...@yahoo.com>:
>> I looked into this more and found that I'd made the default start value false rather than true in the jaxb model.  I added some comments to the schema copes and fixed this, now features appear to start automatically when installed.
>> 
>> This problem didn't have anything to do with boot features.... which indicates to me that trunk is not getting any significant testing..... not a good sign if we want to release it soon.
>> 
>> thanks
>> david jencks
>> 
>> On Apr 19, 2011, at 4:32 AM, Christian Schneider wrote:
>> 
>>> +1
>>> For auto starting features by default
>>> 
>>> Christian
>>> 
>>> 
>>> Am 19.04.2011 09:05, schrieb Achim Nierbeck:
>>>> hm,
>>>> 
>>>> I only have one open question, the other "standard" features like war
>>>> and webconsole, when I install those features the bundles stay in
>>>> installed state, and some
>>>> of those bundles are supposed to be system bundles, e.g. the web
>>>> console bundle. I kind of miss the standard behaviour of installing a
>>>> feature and all bundles are up and running. How do we get around that?
>>>> And actually the current behavior of installing a feature and those
>>>> features are right available is one of the best things about the
>>>> features. I'd rather like to see it the other way round.
>>>> 
>>>> Default behavior should be the same as before, if a feature is
>>>> installed all bundles are started right away, if I don't want it that
>>>> way I need to add a special flag like --nostart or something.
>>>> 
>>>> regards, Achim
>>>> 
>>>> 2011/4/19 David Jencks<da...@yahoo.com>:
>>>>> In r1094800 I adopted these ideas.  The biggest change to review is adding a "forceStart" option to the FeaturesService options.  This is so we can assure that all bundles in boot features get started.   I thought I remembered a -s features:install option that would start all the bundles, but it doesn't seem to be there today.  If no one objects to this enum option I think we should add the command option.
>>>>> 
>>>>> In addition I made a new feature called "standard" in the standard features which contains the stuff from framework that can easily be installed as a boot feature.  I also made the full kar's feature installed as a boot feature.
>>>>> 
>>>>> The servers (old and new) seem to start OK for me and have the expected content.  Please check for problems.
>>>>> 
>>>>> thanks
>>>>> david jencks
>>>>> 
>>>>> On Apr 18, 2011, at 12:15 AM, David Jencks wrote:
>>>>> 
>>>>>> I think there's a problem with boot features, and I think we don't see it with the old style assemblies because the bundles are in fact all listed in the startup.properties as well as as boot features.
>>>>>> 
>>>>>> There are 3 bundles in other parts of the startup.properties that depend on  Apache Karaf :: Management (3.0.0.SNAPSHOT):
>>>>>> 
>>>>>> [  14] [Installed  ] [            ] [   30] Apache Karaf :: Diagnostic :: Management (3.0.0.SNAPSHOT)
>>>>>> [  16] [Installed  ] [            ] [   30] Apache Karaf :: Features :: Management (3.0.0.SNAPSHOT)
>>>>>> [  19] [Installed  ] [            ] [   30] Apache Karaf :: Admin :: Management (3.0.0.SNAPSHOT)
>>>>>> 
>>>>>> Even if I put the feature core bundle at start level 25 it installs the boot feature asynchronously so the management bundle isn't installed by the time these 3 bundles need it.
>>>>>> I'm not 100% sure but I think this problem still occurs if I make the feature service install the boot features synchronously.  I'm surprised but can't debug through it tonight.
>>>>>> 
>>>>>> One possible fix might be to move more of this into boot features so there are no dependencies from startup.properties-started-bundles on boot feature bundles.  This is a pretty big change to the structure of the minimal server.
>>>>>> 
>>>>>> Also the boot features don't appear to be started by default unless I put start='true' into each bundle.
>>>>>> 
>>>>>> Any suggestions?
>>>>>> 
>>>>>> thanks
>>>>>> david jencks
>>>>>> 
>>>>>> 
>>>>>> On Apr 17, 2011, at 12:23 PM, David Jencks wrote:
>>>>>> 
>>>>>>> Hi Guillaume,
>>>>>>> 
>>>>>>> I think you are suggesting:
>>>>>>> 
>>>>>>> 1. combine local-repo and system under a suitable name such as system or repository.  I'll use system for now.
>>>>>>> 
>>>>>>> 2. have as little as possible in startup.properties.  For instance the startup.properties for minimal and full servers should be the same
>>>>>>> 
>>>>>>> 3. everything else in the basic minimal and full servers should be started through bootFeatures.  We want to ensure that all the required bundles are in the (single) repo.
>>>>>>> 
>>>>>>> 4. generally to create a custom server you'll add (or maybe also remove) more bootFeatures and make sure the bundles are installed into the repo.
>>>>>>> 
>>>>>>> This seems entirely reasonable to me.  The only quibble I can think of at the moment is that if everything is in startup.properties you can look at one file and see everything that will be started in one place.
>>>>>>> 
>>>>>>> I'm not sure how it works right now, but with  this approach I think we'll want to make sure that when the features service starts it installs all the boot feature bundles immediately so the framework can use the start level specified in the features and the order listed in bootFeatures won't matter.
>>>>>>> 
>>>>>>> One situation this approach won't work for is if you need some bundles started before  the feature service itself.  For instance if you want jaxb 2.2 used everywhere you'd need to install the jaxb 2.2 system with a lower start level than the feature service.  So some custom servers may need to alter the startup.properties compared to the minimal server.  While in this case I expect the jaxb 2.2 feature I'll need will be in its own feature repo so it can be handled by just listing it as a compile scope dependency, so its bundles will get added to startup.properties, this kind of situation indicates to me that startupFeatures can still be useful.
>>>>>>> 
>>>>>>> I'll see if I run into any problems switching the new-style assemblies to this approach.
>>>>>>> 
>>>>>>> thanks!
>>>>>>> david jencks
>>>>>>> 
>>>>>>> 
>>>>>>> On Apr 17, 2011, at 12:00 PM, Guillaume Nodet wrote:
>>>>>>> 
>>>>>>>> Note that I've recently enhanced the startup mecahnism to not *always*
>>>>>>>> try to install the bundles listed in the startup.properties.
>>>>>>>> Previously, they were always reinstalled at startup time.
>>>>>>>> 
>>>>>>>> First, I don't really see the need for local-repo and system.   I
>>>>>>>> think we should just merge them.
>>>>>>>> 
>>>>>>>> There's really no need for bootFeatures + startupFeatures.  I think we
>>>>>>>> should only have one mechanism.    The original idea was that the core
>>>>>>>> bundles are started with the startup.properties and everthing else
>>>>>>>> installed using features, mostly through bootFeatures.   Now that we
>>>>>>>> have a better maven plugin, the plugin is able to do both, but this is
>>>>>>>> a bit confusing.   Note that there is some differences though:
>>>>>>>> * bundles listed startup.properties have to be in the system repo as
>>>>>>>> the real mvn url handlers can't be used
>>>>>>>> * manually editing the statup.properties is much more tedious than
>>>>>>>> changing the bootFeatures imho
>>>>>>>> * you can't put bundles using wrap url handler in the startup.properties
>>>>>>>> The third point is specially problematic I think.  One possible use
>>>>>>>> case that isn't really addressed yet is the ability to create a
>>>>>>>> configuration where some features depend on url handlers that are
>>>>>>>> provisioned by other features.   Or, said another way, a feature can
>>>>>>>> only be *installed* if a dependent feature is *started*.   I think
>>>>>>>> moving things back in the startup.properties will make such
>>>>>>>> dependencies even harder to manage.
>>>>>>>> 
>>>>>>>> I think I would have rathe gone the opposite direction and remove as
>>>>>>>> much as possible from the startup.properties to use the bootfeatures
>>>>>>>> instead, but it may be just me.
>>>>>>>> 
>>>>>>>> Just to understand the goal, what kind of benefit do you see by
>>>>>>>> listing all bundles in the startup.properties ?  I suppose we could
>>>>>>>> get rid of the features service at runtime then, but apart from that,
>>>>>>>> I'm not sure to see.
>>>>>>>> 
>>>>>>>> On Sun, Apr 17, 2011 at 09:41, David Jencks<da...@yahoo.com>  wrote:
>>>>>>>>> Well, I think it may promote confusion, but there are now 3 options for features in features repositories of maven runtime scope:
>>>>>>>>> 
>>>>>>>>> startupFeatures.  The bundles in these features will get installed into system and listed in startup.properties
>>>>>>>>> 
>>>>>>>>> bootFeatures: The bundles in these features will get installed into local-repo and the feature names added to  bootFeatures in the features cfg file
>>>>>>>>> 
>>>>>>>>> installedFeatures: The bundles in these features will get installed into local-repo.
>>>>>>>>> 
>>>>>>>>> For instance,
>>>>>>>>> 
>>>>>>>>>              <configuration>
>>>>>>>>>                  <startupFeatures>
>>>>>>>>>                      <feature>ssh</feature>
>>>>>>>>>                      <feature>config</feature>
>>>>>>>>>                      <feature>management</feature>
>>>>>>>>>                  </startupFeatures>
>>>>>>>>>              </configuration>
>>>>>>>>> 
>>>>>>>>> Note that except for startupFeatures the bundles are installed into local-repo.  I think system should only have bundles started from startup.properties in it.
>>>>>>>>> 
>>>>>>>>> thoughts?
>>>>>>>>> 
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>> 
>>>>>>>>> On Apr 16, 2011, at 12:50 PM, Johan Edstrom wrote:
>>>>>>>>> 
>>>>>>>>>> For me it'd be the same logic as not "starting" everything from tomcats endorsed lib and
>>>>>>>>>> just deploying WAR file, perhaps a little convoluted comparison, but the features additions, adding
>>>>>>>>>> things and keeping "application" vs. features does make it simpler to manage as your features and deployments grow.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Apr 16, 2011, at 1:05 PM, David Jencks wrote:
>>>>>>>>>> 
>>>>>>>>>>> If the same bundles all get started when you start the server, what is the difference?  I think you've "designed" the server you want by including the bundles and indicating that you want them started at server startup.  How is it different whether the bundles are started from startup.properties or the feature service looking at boot features?
>>>>>>>>>>> 
>>>>>>>>>>> thanks
>>>>>>>>>>> david jencks
>>>>>>>>>>> 
>>>>>>>>>>> On Apr 16, 2011, at 11:48 AM, Johan Edstrom wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> I really think that the startup.properties is for infrastructure, bluperint etc.
>>>>>>>>>>>> the startup features allows you do "design" your own distro.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Apr 16, 2011, at 12:42 PM, David Jencks wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi JB,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks for the explanation, I think I've looked at things from only the karaf-assembly point of view too long to see anything else :-)  The way karaf-assembly works now, all the bundles in system will be listed in startup.properties and will start automatically.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I think you are saying:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -- if you include a feature in the boot feature list, you should make sure all the bundles needed are in the server already.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> and, looking more closely at the add-features-to-repo mojo I see there's a<features>  configuration element that lets you specify features to install the bundles for.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I'm going to add that capability to the karaf-assembly packaging.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> There's another difference of style to resolve.  I've set up the karaf-assembly packaging so that whenever it installs a featue, it adds the feature's bundles to startup.properties at the appropriate start level.  For "boot" features this means that you don't need to list them in the features service configuration "boot features" since they will be started via the startup.properties.  On the other hand you can't uninstall this feature so easily.  Is this an important difference? Do I need to make a way to install a feature's bundles but not add the bundles to startup.properties?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> many thanks
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Apr 16, 2011, at 12:12 AM, Jean-Baptiste Onofré wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I'm not sure to follow you. bootFeatures property defines which features are started at Karaf bootstrap time. It allows user to start a fresh Karaf instance with a set of Karaf features loaded and installed.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> For instance, in ServiceMix, we have:
>>>>>>>>>>>>>> - nmr feature as boot feature and we ship all required jar (using features-add-to-repo goal) in the system OBR
>>>>>>>>>>>>>> - camel-nmr, cxf-nmr, etc are part of the NMR features but not in the boot features set. As we consider this kind of features as optional, we don't ship the features jar in the system OBR
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>> JB
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 04/16/2011 08:32 AM, David Jencks wrote:
>>>>>>>>>>>>>>> I am wondering why we have boot features in trunk.  In particular I think there is an inconsistency around the management feature which is in the minimal boot feature list and whose jars are in the minimal server assembly.  On the other hand the ssh full boot feature doesn't have all its jars in the full server.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> If a boot feature doesn't already have all its jars in the server, won't this require internet access on initial startup?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> If all the jars for a boot feature are already installed in the server, why call it a boot feature, why not just start it with the rest of the jars?  For this question I may be biased by looking at the packaging based assemblies where the startup.properties is constructed from the features that are installed into the server, so it is at least as east to configure the assembly to just include the jars as to configure a boot feature.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Am I missing something?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Cheers,
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> Open Source SOA
>>>>>>>> http://fusesource.com
>>>>>>>> 
>>>>>>>> Connect at CamelOne May 24-26
>>>>>>>> The Open Source Integration Conference
>>>>>>>> http://camelone.com/
>>>>> 
>>> 
>>> --
>>> Christian Schneider
>>> CXF and Camel Architect
>>> SOPERA - The Application Integration Division of Talend
>>> http://www.talend.com
>>> 
>> 
>>

Re: Please review! Re: Why boot features?

Posted by Christian Schneider <ch...@die-schneider.net>.

Well i saw this but thought it was on purpose

Christian

Von meinem iPhone gesendet

Am 19.04.2011 um 20:46 schrieb David Jencks <da...@yahoo.com>:

> I looked into this more and found that I'd made the default start value false rather than true in the jaxb model.  I added some comments to the schema copes and fixed this, now features appear to start automatically when installed.
> 
> This problem didn't have anything to do with boot features.... which indicates to me that trunk is not getting any significant testing..... not a good sign if we want to release it soon.
> 
> thanks
> david jencks
> 
> On Apr 19, 2011, at 4:32 AM, Christian Schneider wrote:
> 
>> +1
>> For auto starting features by default
>> 
>> Christian
>> 
>> 
>> Am 19.04.2011 09:05, schrieb Achim Nierbeck:
>>> hm,
>>> 
>>> I only have one open question, the other "standard" features like war
>>> and webconsole, when I install those features the bundles stay in
>>> installed state, and some
>>> of those bundles are supposed to be system bundles, e.g. the web
>>> console bundle. I kind of miss the standard behaviour of installing a
>>> feature and all bundles are up and running. How do we get around that?
>>> And actually the current behavior of installing a feature and those
>>> features are right available is one of the best things about the
>>> features. I'd rather like to see it the other way round.
>>> 
>>> Default behavior should be the same as before, if a feature is
>>> installed all bundles are started right away, if I don't want it that
>>> way I need to add a special flag like --nostart or something.
>>> 
>>> regards, Achim
>>> 
>>> 2011/4/19 David Jencks<da...@yahoo.com>:
>>>> In r1094800 I adopted these ideas.  The biggest change to review is adding a "forceStart" option to the FeaturesService options.  This is so we can assure that all bundles in boot features get started.   I thought I remembered a -s features:install option that would start all the bundles, but it doesn't seem to be there today.  If no one objects to this enum option I think we should add the command option.
>>>> 
>>>> In addition I made a new feature called "standard" in the standard features which contains the stuff from framework that can easily be installed as a boot feature.  I also made the full kar's feature installed as a boot feature.
>>>> 
>>>> The servers (old and new) seem to start OK for me and have the expected content.  Please check for problems.
>>>> 
>>>> thanks
>>>> david jencks
>>>> 
>>>> On Apr 18, 2011, at 12:15 AM, David Jencks wrote:
>>>> 
>>>>> I think there's a problem with boot features, and I think we don't see it with the old style assemblies because the bundles are in fact all listed in the startup.properties as well as as boot features.
>>>>> 
>>>>> There are 3 bundles in other parts of the startup.properties that depend on  Apache Karaf :: Management (3.0.0.SNAPSHOT):
>>>>> 
>>>>> [  14] [Installed  ] [            ] [   30] Apache Karaf :: Diagnostic :: Management (3.0.0.SNAPSHOT)
>>>>> [  16] [Installed  ] [            ] [   30] Apache Karaf :: Features :: Management (3.0.0.SNAPSHOT)
>>>>> [  19] [Installed  ] [            ] [   30] Apache Karaf :: Admin :: Management (3.0.0.SNAPSHOT)
>>>>> 
>>>>> Even if I put the feature core bundle at start level 25 it installs the boot feature asynchronously so the management bundle isn't installed by the time these 3 bundles need it.
>>>>> I'm not 100% sure but I think this problem still occurs if I make the feature service install the boot features synchronously.  I'm surprised but can't debug through it tonight.
>>>>> 
>>>>> One possible fix might be to move more of this into boot features so there are no dependencies from startup.properties-started-bundles on boot feature bundles.  This is a pretty big change to the structure of the minimal server.
>>>>> 
>>>>> Also the boot features don't appear to be started by default unless I put start='true' into each bundle.
>>>>> 
>>>>> Any suggestions?
>>>>> 
>>>>> thanks
>>>>> david jencks
>>>>> 
>>>>> 
>>>>> On Apr 17, 2011, at 12:23 PM, David Jencks wrote:
>>>>> 
>>>>>> Hi Guillaume,
>>>>>> 
>>>>>> I think you are suggesting:
>>>>>> 
>>>>>> 1. combine local-repo and system under a suitable name such as system or repository.  I'll use system for now.
>>>>>> 
>>>>>> 2. have as little as possible in startup.properties.  For instance the startup.properties for minimal and full servers should be the same
>>>>>> 
>>>>>> 3. everything else in the basic minimal and full servers should be started through bootFeatures.  We want to ensure that all the required bundles are in the (single) repo.
>>>>>> 
>>>>>> 4. generally to create a custom server you'll add (or maybe also remove) more bootFeatures and make sure the bundles are installed into the repo.
>>>>>> 
>>>>>> This seems entirely reasonable to me.  The only quibble I can think of at the moment is that if everything is in startup.properties you can look at one file and see everything that will be started in one place.
>>>>>> 
>>>>>> I'm not sure how it works right now, but with  this approach I think we'll want to make sure that when the features service starts it installs all the boot feature bundles immediately so the framework can use the start level specified in the features and the order listed in bootFeatures won't matter.
>>>>>> 
>>>>>> One situation this approach won't work for is if you need some bundles started before  the feature service itself.  For instance if you want jaxb 2.2 used everywhere you'd need to install the jaxb 2.2 system with a lower start level than the feature service.  So some custom servers may need to alter the startup.properties compared to the minimal server.  While in this case I expect the jaxb 2.2 feature I'll need will be in its own feature repo so it can be handled by just listing it as a compile scope dependency, so its bundles will get added to startup.properties, this kind of situation indicates to me that startupFeatures can still be useful.
>>>>>> 
>>>>>> I'll see if I run into any problems switching the new-style assemblies to this approach.
>>>>>> 
>>>>>> thanks!
>>>>>> david jencks
>>>>>> 
>>>>>> 
>>>>>> On Apr 17, 2011, at 12:00 PM, Guillaume Nodet wrote:
>>>>>> 
>>>>>>> Note that I've recently enhanced the startup mecahnism to not *always*
>>>>>>> try to install the bundles listed in the startup.properties.
>>>>>>> Previously, they were always reinstalled at startup time.
>>>>>>> 
>>>>>>> First, I don't really see the need for local-repo and system.   I
>>>>>>> think we should just merge them.
>>>>>>> 
>>>>>>> There's really no need for bootFeatures + startupFeatures.  I think we
>>>>>>> should only have one mechanism.    The original idea was that the core
>>>>>>> bundles are started with the startup.properties and everthing else
>>>>>>> installed using features, mostly through bootFeatures.   Now that we
>>>>>>> have a better maven plugin, the plugin is able to do both, but this is
>>>>>>> a bit confusing.   Note that there is some differences though:
>>>>>>> * bundles listed startup.properties have to be in the system repo as
>>>>>>> the real mvn url handlers can't be used
>>>>>>> * manually editing the statup.properties is much more tedious than
>>>>>>> changing the bootFeatures imho
>>>>>>> * you can't put bundles using wrap url handler in the startup.properties
>>>>>>> The third point is specially problematic I think.  One possible use
>>>>>>> case that isn't really addressed yet is the ability to create a
>>>>>>> configuration where some features depend on url handlers that are
>>>>>>> provisioned by other features.   Or, said another way, a feature can
>>>>>>> only be *installed* if a dependent feature is *started*.   I think
>>>>>>> moving things back in the startup.properties will make such
>>>>>>> dependencies even harder to manage.
>>>>>>> 
>>>>>>> I think I would have rathe gone the opposite direction and remove as
>>>>>>> much as possible from the startup.properties to use the bootfeatures
>>>>>>> instead, but it may be just me.
>>>>>>> 
>>>>>>> Just to understand the goal, what kind of benefit do you see by
>>>>>>> listing all bundles in the startup.properties ?  I suppose we could
>>>>>>> get rid of the features service at runtime then, but apart from that,
>>>>>>> I'm not sure to see.
>>>>>>> 
>>>>>>> On Sun, Apr 17, 2011 at 09:41, David Jencks<da...@yahoo.com>  wrote:
>>>>>>>> Well, I think it may promote confusion, but there are now 3 options for features in features repositories of maven runtime scope:
>>>>>>>> 
>>>>>>>> startupFeatures.  The bundles in these features will get installed into system and listed in startup.properties
>>>>>>>> 
>>>>>>>> bootFeatures: The bundles in these features will get installed into local-repo and the feature names added to  bootFeatures in the features cfg file
>>>>>>>> 
>>>>>>>> installedFeatures: The bundles in these features will get installed into local-repo.
>>>>>>>> 
>>>>>>>> For instance,
>>>>>>>> 
>>>>>>>>             <configuration>
>>>>>>>>                 <startupFeatures>
>>>>>>>>                     <feature>ssh</feature>
>>>>>>>>                     <feature>config</feature>
>>>>>>>>                     <feature>management</feature>
>>>>>>>>                 </startupFeatures>
>>>>>>>>             </configuration>
>>>>>>>> 
>>>>>>>> Note that except for startupFeatures the bundles are installed into local-repo.  I think system should only have bundles started from startup.properties in it.
>>>>>>>> 
>>>>>>>> thoughts?
>>>>>>>> 
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>> 
>>>>>>>> On Apr 16, 2011, at 12:50 PM, Johan Edstrom wrote:
>>>>>>>> 
>>>>>>>>> For me it'd be the same logic as not "starting" everything from tomcats endorsed lib and
>>>>>>>>> just deploying WAR file, perhaps a little convoluted comparison, but the features additions, adding
>>>>>>>>> things and keeping "application" vs. features does make it simpler to manage as your features and deployments grow.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Apr 16, 2011, at 1:05 PM, David Jencks wrote:
>>>>>>>>> 
>>>>>>>>>> If the same bundles all get started when you start the server, what is the difference?  I think you've "designed" the server you want by including the bundles and indicating that you want them started at server startup.  How is it different whether the bundles are started from startup.properties or the feature service looking at boot features?
>>>>>>>>>> 
>>>>>>>>>> thanks
>>>>>>>>>> david jencks
>>>>>>>>>> 
>>>>>>>>>> On Apr 16, 2011, at 11:48 AM, Johan Edstrom wrote:
>>>>>>>>>> 
>>>>>>>>>>> I really think that the startup.properties is for infrastructure, bluperint etc.
>>>>>>>>>>> the startup features allows you do "design" your own distro.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Apr 16, 2011, at 12:42 PM, David Jencks wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Hi JB,
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks for the explanation, I think I've looked at things from only the karaf-assembly point of view too long to see anything else :-)  The way karaf-assembly works now, all the bundles in system will be listed in startup.properties and will start automatically.
>>>>>>>>>>>> 
>>>>>>>>>>>> I think you are saying:
>>>>>>>>>>>> 
>>>>>>>>>>>> -- if you include a feature in the boot feature list, you should make sure all the bundles needed are in the server already.
>>>>>>>>>>>> 
>>>>>>>>>>>> and, looking more closely at the add-features-to-repo mojo I see there's a<features>  configuration element that lets you specify features to install the bundles for.
>>>>>>>>>>>> 
>>>>>>>>>>>> I'm going to add that capability to the karaf-assembly packaging.
>>>>>>>>>>>> 
>>>>>>>>>>>> There's another difference of style to resolve.  I've set up the karaf-assembly packaging so that whenever it installs a featue, it adds the feature's bundles to startup.properties at the appropriate start level.  For "boot" features this means that you don't need to list them in the features service configuration "boot features" since they will be started via the startup.properties.  On the other hand you can't uninstall this feature so easily.  Is this an important difference? Do I need to make a way to install a feature's bundles but not add the bundles to startup.properties?
>>>>>>>>>>>> 
>>>>>>>>>>>> many thanks
>>>>>>>>>>>> david jencks
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Apr 16, 2011, at 12:12 AM, Jean-Baptiste Onofré wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I'm not sure to follow you. bootFeatures property defines which features are started at Karaf bootstrap time. It allows user to start a fresh Karaf instance with a set of Karaf features loaded and installed.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> For instance, in ServiceMix, we have:
>>>>>>>>>>>>> - nmr feature as boot feature and we ship all required jar (using features-add-to-repo goal) in the system OBR
>>>>>>>>>>>>> - camel-nmr, cxf-nmr, etc are part of the NMR features but not in the boot features set. As we consider this kind of features as optional, we don't ship the features jar in the system OBR
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> JB
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 04/16/2011 08:32 AM, David Jencks wrote:
>>>>>>>>>>>>>> I am wondering why we have boot features in trunk.  In particular I think there is an inconsistency around the management feature which is in the minimal boot feature list and whose jars are in the minimal server assembly.  On the other hand the ssh full boot feature doesn't have all its jars in the full server.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> If a boot feature doesn't already have all its jars in the server, won't this require internet access on initial startup?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> If all the jars for a boot feature are already installed in the server, why call it a boot feature, why not just start it with the rest of the jars?  For this question I may be biased by looking at the packaging based assemblies where the startup.properties is constructed from the features that are installed into the server, so it is at least as east to configure the assembly to just include the jars as to configure a boot feature.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Am I missing something?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> Open Source SOA
>>>>>>> http://fusesource.com
>>>>>>> 
>>>>>>> Connect at CamelOne May 24-26
>>>>>>> The Open Source Integration Conference
>>>>>>> http://camelone.com/
>>>> 
>> 
>> -- 
>> Christian Schneider
>> CXF and Camel Architect
>> SOPERA - The Application Integration Division of Talend
>> http://www.talend.com
>> 
> 
>

Re: Please review! Re: Why boot features?

Posted by Achim Nierbeck <bc...@googlemail.com>.

Hi David,

thanks for fixing :)

I'm partially trying to get 2.2.1 going, that's probably why 3.0
doesn't get a good testing :)
By the way of testing, last time I looked into the kar produced
artifacts, the bin folder wasn't still included.

regards, Achim

2011/4/19 David Jencks <da...@yahoo.com>:
> I looked into this more and found that I'd made the default start value false rather than true in the jaxb model.  I added some comments to the schema copes and fixed this, now features appear to start automatically when installed.
>
> This problem didn't have anything to do with boot features.... which indicates to me that trunk is not getting any significant testing..... not a good sign if we want to release it soon.
>
> thanks
> david jencks
>
> On Apr 19, 2011, at 4:32 AM, Christian Schneider wrote:
>
>> +1
>> For auto starting features by default
>>
>> Christian
>>
>>
>> Am 19.04.2011 09:05, schrieb Achim Nierbeck:
>>> hm,
>>>
>>> I only have one open question, the other "standard" features like war
>>> and webconsole, when I install those features the bundles stay in
>>> installed state, and some
>>> of those bundles are supposed to be system bundles, e.g. the web
>>> console bundle. I kind of miss the standard behaviour of installing a
>>> feature and all bundles are up and running. How do we get around that?
>>> And actually the current behavior of installing a feature and those
>>> features are right available is one of the best things about the
>>> features. I'd rather like to see it the other way round.
>>>
>>> Default behavior should be the same as before, if a feature is
>>> installed all bundles are started right away, if I don't want it that
>>> way I need to add a special flag like --nostart or something.
>>>
>>> regards, Achim
>>>
>>> 2011/4/19 David Jencks<da...@yahoo.com>:
>>>> In r1094800 I adopted these ideas.  The biggest change to review is adding a "forceStart" option to the FeaturesService options.  This is so we can assure that all bundles in boot features get started.   I thought I remembered a -s features:install option that would start all the bundles, but it doesn't seem to be there today.  If no one objects to this enum option I think we should add the command option.
>>>>
>>>> In addition I made a new feature called "standard" in the standard features which contains the stuff from framework that can easily be installed as a boot feature.  I also made the full kar's feature installed as a boot feature.
>>>>
>>>> The servers (old and new) seem to start OK for me and have the expected content.  Please check for problems.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Apr 18, 2011, at 12:15 AM, David Jencks wrote:
>>>>
>>>>> I think there's a problem with boot features, and I think we don't see it with the old style assemblies because the bundles are in fact all listed in the startup.properties as well as as boot features.
>>>>>
>>>>> There are 3 bundles in other parts of the startup.properties that depend on  Apache Karaf :: Management (3.0.0.SNAPSHOT):
>>>>>
>>>>> [  14] [Installed  ] [            ] [   30] Apache Karaf :: Diagnostic :: Management (3.0.0.SNAPSHOT)
>>>>> [  16] [Installed  ] [            ] [   30] Apache Karaf :: Features :: Management (3.0.0.SNAPSHOT)
>>>>> [  19] [Installed  ] [            ] [   30] Apache Karaf :: Admin :: Management (3.0.0.SNAPSHOT)
>>>>>
>>>>> Even if I put the feature core bundle at start level 25 it installs the boot feature asynchronously so the management bundle isn't installed by the time these 3 bundles need it.
>>>>> I'm not 100% sure but I think this problem still occurs if I make the feature service install the boot features synchronously.  I'm surprised but can't debug through it tonight.
>>>>>
>>>>> One possible fix might be to move more of this into boot features so there are no dependencies from startup.properties-started-bundles on boot feature bundles.  This is a pretty big change to the structure of the minimal server.
>>>>>
>>>>> Also the boot features don't appear to be started by default unless I put start='true' into each bundle.
>>>>>
>>>>> Any suggestions?
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>>
>>>>> On Apr 17, 2011, at 12:23 PM, David Jencks wrote:
>>>>>
>>>>>> Hi Guillaume,
>>>>>>
>>>>>> I think you are suggesting:
>>>>>>
>>>>>> 1. combine local-repo and system under a suitable name such as system or repository.  I'll use system for now.
>>>>>>
>>>>>> 2. have as little as possible in startup.properties.  For instance the startup.properties for minimal and full servers should be the same
>>>>>>
>>>>>> 3. everything else in the basic minimal and full servers should be started through bootFeatures.  We want to ensure that all the required bundles are in the (single) repo.
>>>>>>
>>>>>> 4. generally to create a custom server you'll add (or maybe also remove) more bootFeatures and make sure the bundles are installed into the repo.
>>>>>>
>>>>>> This seems entirely reasonable to me.  The only quibble I can think of at the moment is that if everything is in startup.properties you can look at one file and see everything that will be started in one place.
>>>>>>
>>>>>> I'm not sure how it works right now, but with  this approach I think we'll want to make sure that when the features service starts it installs all the boot feature bundles immediately so the framework can use the start level specified in the features and the order listed in bootFeatures won't matter.
>>>>>>
>>>>>> One situation this approach won't work for is if you need some bundles started before  the feature service itself.  For instance if you want jaxb 2.2 used everywhere you'd need to install the jaxb 2.2 system with a lower start level than the feature service.  So some custom servers may need to alter the startup.properties compared to the minimal server.  While in this case I expect the jaxb 2.2 feature I'll need will be in its own feature repo so it can be handled by just listing it as a compile scope dependency, so its bundles will get added to startup.properties, this kind of situation indicates to me that startupFeatures can still be useful.
>>>>>>
>>>>>> I'll see if I run into any problems switching the new-style assemblies to this approach.
>>>>>>
>>>>>> thanks!
>>>>>> david jencks
>>>>>>
>>>>>>
>>>>>> On Apr 17, 2011, at 12:00 PM, Guillaume Nodet wrote:
>>>>>>
>>>>>>> Note that I've recently enhanced the startup mecahnism to not *always*
>>>>>>> try to install the bundles listed in the startup.properties.
>>>>>>> Previously, they were always reinstalled at startup time.
>>>>>>>
>>>>>>> First, I don't really see the need for local-repo and system.   I
>>>>>>> think we should just merge them.
>>>>>>>
>>>>>>> There's really no need for bootFeatures + startupFeatures.  I think we
>>>>>>> should only have one mechanism.    The original idea was that the core
>>>>>>> bundles are started with the startup.properties and everthing else
>>>>>>> installed using features, mostly through bootFeatures.   Now that we
>>>>>>> have a better maven plugin, the plugin is able to do both, but this is
>>>>>>> a bit confusing.   Note that there is some differences though:
>>>>>>> * bundles listed startup.properties have to be in the system repo as
>>>>>>> the real mvn url handlers can't be used
>>>>>>> * manually editing the statup.properties is much more tedious than
>>>>>>> changing the bootFeatures imho
>>>>>>> * you can't put bundles using wrap url handler in the startup.properties
>>>>>>> The third point is specially problematic I think.  One possible use
>>>>>>> case that isn't really addressed yet is the ability to create a
>>>>>>> configuration where some features depend on url handlers that are
>>>>>>> provisioned by other features.   Or, said another way, a feature can
>>>>>>> only be *installed* if a dependent feature is *started*.   I think
>>>>>>> moving things back in the startup.properties will make such
>>>>>>> dependencies even harder to manage.
>>>>>>>
>>>>>>> I think I would have rathe gone the opposite direction and remove as
>>>>>>> much as possible from the startup.properties to use the bootfeatures
>>>>>>> instead, but it may be just me.
>>>>>>>
>>>>>>> Just to understand the goal, what kind of benefit do you see by
>>>>>>> listing all bundles in the startup.properties ?  I suppose we could
>>>>>>> get rid of the features service at runtime then, but apart from that,
>>>>>>> I'm not sure to see.
>>>>>>>
>>>>>>> On Sun, Apr 17, 2011 at 09:41, David Jencks<da...@yahoo.com>  wrote:
>>>>>>>> Well, I think it may promote confusion, but there are now 3 options for features in features repositories of maven runtime scope:
>>>>>>>>
>>>>>>>> startupFeatures.  The bundles in these features will get installed into system and listed in startup.properties
>>>>>>>>
>>>>>>>> bootFeatures: The bundles in these features will get installed into local-repo and the feature names added to  bootFeatures in the features cfg file
>>>>>>>>
>>>>>>>> installedFeatures: The bundles in these features will get installed into local-repo.
>>>>>>>>
>>>>>>>> For instance,
>>>>>>>>
>>>>>>>>              <configuration>
>>>>>>>>                  <startupFeatures>
>>>>>>>>                      <feature>ssh</feature>
>>>>>>>>                      <feature>config</feature>
>>>>>>>>                      <feature>management</feature>
>>>>>>>>                  </startupFeatures>
>>>>>>>>              </configuration>
>>>>>>>>
>>>>>>>> Note that except for startupFeatures the bundles are installed into local-repo.  I think system should only have bundles started from startup.properties in it.
>>>>>>>>
>>>>>>>> thoughts?
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On Apr 16, 2011, at 12:50 PM, Johan Edstrom wrote:
>>>>>>>>
>>>>>>>>> For me it'd be the same logic as not "starting" everything from tomcats endorsed lib and
>>>>>>>>> just deploying WAR file, perhaps a little convoluted comparison, but the features additions, adding
>>>>>>>>> things and keeping "application" vs. features does make it simpler to manage as your features and deployments grow.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Apr 16, 2011, at 1:05 PM, David Jencks wrote:
>>>>>>>>>
>>>>>>>>>> If the same bundles all get started when you start the server, what is the difference?  I think you've "designed" the server you want by including the bundles and indicating that you want them started at server startup.  How is it different whether the bundles are started from startup.properties or the feature service looking at boot features?
>>>>>>>>>>
>>>>>>>>>> thanks
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>> On Apr 16, 2011, at 11:48 AM, Johan Edstrom wrote:
>>>>>>>>>>
>>>>>>>>>>> I really think that the startup.properties is for infrastructure, bluperint etc.
>>>>>>>>>>> the startup features allows you do "design" your own distro.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Apr 16, 2011, at 12:42 PM, David Jencks wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi JB,
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the explanation, I think I've looked at things from only the karaf-assembly point of view too long to see anything else :-)  The way karaf-assembly works now, all the bundles in system will be listed in startup.properties and will start automatically.
>>>>>>>>>>>>
>>>>>>>>>>>> I think you are saying:
>>>>>>>>>>>>
>>>>>>>>>>>> -- if you include a feature in the boot feature list, you should make sure all the bundles needed are in the server already.
>>>>>>>>>>>>
>>>>>>>>>>>> and, looking more closely at the add-features-to-repo mojo I see there's a<features>  configuration element that lets you specify features to install the bundles for.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm going to add that capability to the karaf-assembly packaging.
>>>>>>>>>>>>
>>>>>>>>>>>> There's another difference of style to resolve.  I've set up the karaf-assembly packaging so that whenever it installs a featue, it adds the feature's bundles to startup.properties at the appropriate start level.  For "boot" features this means that you don't need to list them in the features service configuration "boot features" since they will be started via the startup.properties.  On the other hand you can't uninstall this feature so easily.  Is this an important difference? Do I need to make a way to install a feature's bundles but not add the bundles to startup.properties?
>>>>>>>>>>>>
>>>>>>>>>>>> many thanks
>>>>>>>>>>>> david jencks
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Apr 16, 2011, at 12:12 AM, Jean-Baptiste Onofré wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm not sure to follow you. bootFeatures property defines which features are started at Karaf bootstrap time. It allows user to start a fresh Karaf instance with a set of Karaf features loaded and installed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For instance, in ServiceMix, we have:
>>>>>>>>>>>>> - nmr feature as boot feature and we ship all required jar (using features-add-to-repo goal) in the system OBR
>>>>>>>>>>>>> - camel-nmr, cxf-nmr, etc are part of the NMR features but not in the boot features set. As we consider this kind of features as optional, we don't ship the features jar in the system OBR
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> JB
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 04/16/2011 08:32 AM, David Jencks wrote:
>>>>>>>>>>>>>> I am wondering why we have boot features in trunk.  In particular I think there is an inconsistency around the management feature which is in the minimal boot feature list and whose jars are in the minimal server assembly.  On the other hand the ssh full boot feature doesn't have all its jars in the full server.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If a boot feature doesn't already have all its jars in the server, won't this require internet access on initial startup?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If all the jars for a boot feature are already installed in the server, why call it a boot feature, why not just start it with the rest of the jars?  For this question I may be biased by looking at the packaging based assemblies where the startup.properties is constructed from the features that are installed into the server, so it is at least as east to configure the assembly to just include the jars as to configure a boot feature.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am I missing something?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> Open Source SOA
>>>>>>> http://fusesource.com
>>>>>>>
>>>>>>> Connect at CamelOne May 24-26
>>>>>>> The Open Source Integration Conference
>>>>>>> http://camelone.com/
>>>>
>>
>> --
>> Christian Schneider
>> CXF and Camel Architect
>> SOPERA - The Application Integration Division of Talend
>> http://www.talend.com
>>
>
>

Re: Please review! Re: Why boot features?

Posted by David Jencks <da...@yahoo.com>.

I looked into this more and found that I'd made the default start value false rather than true in the jaxb model.  I added some comments to the schema copes and fixed this, now features appear to start automatically when installed.

This problem didn't have anything to do with boot features.... which indicates to me that trunk is not getting any significant testing..... not a good sign if we want to release it soon.

thanks
david jencks

On Apr 19, 2011, at 4:32 AM, Christian Schneider wrote:

> +1
> For auto starting features by default
> 
> Christian
> 
> 
> Am 19.04.2011 09:05, schrieb Achim Nierbeck:
>> hm,
>> 
>> I only have one open question, the other "standard" features like war
>> and webconsole, when I install those features the bundles stay in
>> installed state, and some
>> of those bundles are supposed to be system bundles, e.g. the web
>> console bundle. I kind of miss the standard behaviour of installing a
>> feature and all bundles are up and running. How do we get around that?
>> And actually the current behavior of installing a feature and those
>> features are right available is one of the best things about the
>> features. I'd rather like to see it the other way round.
>> 
>> Default behavior should be the same as before, if a feature is
>> installed all bundles are started right away, if I don't want it that
>> way I need to add a special flag like --nostart or something.
>> 
>> regards, Achim
>> 
>> 2011/4/19 David Jencks<da...@yahoo.com>:
>>> In r1094800 I adopted these ideas.  The biggest change to review is adding a "forceStart" option to the FeaturesService options.  This is so we can assure that all bundles in boot features get started.   I thought I remembered a -s features:install option that would start all the bundles, but it doesn't seem to be there today.  If no one objects to this enum option I think we should add the command option.
>>> 
>>> In addition I made a new feature called "standard" in the standard features which contains the stuff from framework that can easily be installed as a boot feature.  I also made the full kar's feature installed as a boot feature.
>>> 
>>> The servers (old and new) seem to start OK for me and have the expected content.  Please check for problems.
>>> 
>>> thanks
>>> david jencks
>>> 
>>> On Apr 18, 2011, at 12:15 AM, David Jencks wrote:
>>> 
>>>> I think there's a problem with boot features, and I think we don't see it with the old style assemblies because the bundles are in fact all listed in the startup.properties as well as as boot features.
>>>> 
>>>> There are 3 bundles in other parts of the startup.properties that depend on  Apache Karaf :: Management (3.0.0.SNAPSHOT):
>>>> 
>>>> [  14] [Installed  ] [            ] [   30] Apache Karaf :: Diagnostic :: Management (3.0.0.SNAPSHOT)
>>>> [  16] [Installed  ] [            ] [   30] Apache Karaf :: Features :: Management (3.0.0.SNAPSHOT)
>>>> [  19] [Installed  ] [            ] [   30] Apache Karaf :: Admin :: Management (3.0.0.SNAPSHOT)
>>>> 
>>>> Even if I put the feature core bundle at start level 25 it installs the boot feature asynchronously so the management bundle isn't installed by the time these 3 bundles need it.
>>>> I'm not 100% sure but I think this problem still occurs if I make the feature service install the boot features synchronously.  I'm surprised but can't debug through it tonight.
>>>> 
>>>> One possible fix might be to move more of this into boot features so there are no dependencies from startup.properties-started-bundles on boot feature bundles.  This is a pretty big change to the structure of the minimal server.
>>>> 
>>>> Also the boot features don't appear to be started by default unless I put start='true' into each bundle.
>>>> 
>>>> Any suggestions?
>>>> 
>>>> thanks
>>>> david jencks
>>>> 
>>>> 
>>>> On Apr 17, 2011, at 12:23 PM, David Jencks wrote:
>>>> 
>>>>> Hi Guillaume,
>>>>> 
>>>>> I think you are suggesting:
>>>>> 
>>>>> 1. combine local-repo and system under a suitable name such as system or repository.  I'll use system for now.
>>>>> 
>>>>> 2. have as little as possible in startup.properties.  For instance the startup.properties for minimal and full servers should be the same
>>>>> 
>>>>> 3. everything else in the basic minimal and full servers should be started through bootFeatures.  We want to ensure that all the required bundles are in the (single) repo.
>>>>> 
>>>>> 4. generally to create a custom server you'll add (or maybe also remove) more bootFeatures and make sure the bundles are installed into the repo.
>>>>> 
>>>>> This seems entirely reasonable to me.  The only quibble I can think of at the moment is that if everything is in startup.properties you can look at one file and see everything that will be started in one place.
>>>>> 
>>>>> I'm not sure how it works right now, but with  this approach I think we'll want to make sure that when the features service starts it installs all the boot feature bundles immediately so the framework can use the start level specified in the features and the order listed in bootFeatures won't matter.
>>>>> 
>>>>> One situation this approach won't work for is if you need some bundles started before  the feature service itself.  For instance if you want jaxb 2.2 used everywhere you'd need to install the jaxb 2.2 system with a lower start level than the feature service.  So some custom servers may need to alter the startup.properties compared to the minimal server.  While in this case I expect the jaxb 2.2 feature I'll need will be in its own feature repo so it can be handled by just listing it as a compile scope dependency, so its bundles will get added to startup.properties, this kind of situation indicates to me that startupFeatures can still be useful.
>>>>> 
>>>>> I'll see if I run into any problems switching the new-style assemblies to this approach.
>>>>> 
>>>>> thanks!
>>>>> david jencks
>>>>> 
>>>>> 
>>>>> On Apr 17, 2011, at 12:00 PM, Guillaume Nodet wrote:
>>>>> 
>>>>>> Note that I've recently enhanced the startup mecahnism to not *always*
>>>>>> try to install the bundles listed in the startup.properties.
>>>>>> Previously, they were always reinstalled at startup time.
>>>>>> 
>>>>>> First, I don't really see the need for local-repo and system.   I
>>>>>> think we should just merge them.
>>>>>> 
>>>>>> There's really no need for bootFeatures + startupFeatures.  I think we
>>>>>> should only have one mechanism.    The original idea was that the core
>>>>>> bundles are started with the startup.properties and everthing else
>>>>>> installed using features, mostly through bootFeatures.   Now that we
>>>>>> have a better maven plugin, the plugin is able to do both, but this is
>>>>>> a bit confusing.   Note that there is some differences though:
>>>>>> * bundles listed startup.properties have to be in the system repo as
>>>>>> the real mvn url handlers can't be used
>>>>>> * manually editing the statup.properties is much more tedious than
>>>>>> changing the bootFeatures imho
>>>>>> * you can't put bundles using wrap url handler in the startup.properties
>>>>>> The third point is specially problematic I think.  One possible use
>>>>>> case that isn't really addressed yet is the ability to create a
>>>>>> configuration where some features depend on url handlers that are
>>>>>> provisioned by other features.   Or, said another way, a feature can
>>>>>> only be *installed* if a dependent feature is *started*.   I think
>>>>>> moving things back in the startup.properties will make such
>>>>>> dependencies even harder to manage.
>>>>>> 
>>>>>> I think I would have rathe gone the opposite direction and remove as
>>>>>> much as possible from the startup.properties to use the bootfeatures
>>>>>> instead, but it may be just me.
>>>>>> 
>>>>>> Just to understand the goal, what kind of benefit do you see by
>>>>>> listing all bundles in the startup.properties ?  I suppose we could
>>>>>> get rid of the features service at runtime then, but apart from that,
>>>>>> I'm not sure to see.
>>>>>> 
>>>>>> On Sun, Apr 17, 2011 at 09:41, David Jencks<da...@yahoo.com>  wrote:
>>>>>>> Well, I think it may promote confusion, but there are now 3 options for features in features repositories of maven runtime scope:
>>>>>>> 
>>>>>>> startupFeatures.  The bundles in these features will get installed into system and listed in startup.properties
>>>>>>> 
>>>>>>> bootFeatures: The bundles in these features will get installed into local-repo and the feature names added to  bootFeatures in the features cfg file
>>>>>>> 
>>>>>>> installedFeatures: The bundles in these features will get installed into local-repo.
>>>>>>> 
>>>>>>> For instance,
>>>>>>> 
>>>>>>>              <configuration>
>>>>>>>                  <startupFeatures>
>>>>>>>                      <feature>ssh</feature>
>>>>>>>                      <feature>config</feature>
>>>>>>>                      <feature>management</feature>
>>>>>>>                  </startupFeatures>
>>>>>>>              </configuration>
>>>>>>> 
>>>>>>> Note that except for startupFeatures the bundles are installed into local-repo.  I think system should only have bundles started from startup.properties in it.
>>>>>>> 
>>>>>>> thoughts?
>>>>>>> 
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>> 
>>>>>>> On Apr 16, 2011, at 12:50 PM, Johan Edstrom wrote:
>>>>>>> 
>>>>>>>> For me it'd be the same logic as not "starting" everything from tomcats endorsed lib and
>>>>>>>> just deploying WAR file, perhaps a little convoluted comparison, but the features additions, adding
>>>>>>>> things and keeping "application" vs. features does make it simpler to manage as your features and deployments grow.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Apr 16, 2011, at 1:05 PM, David Jencks wrote:
>>>>>>>> 
>>>>>>>>> If the same bundles all get started when you start the server, what is the difference?  I think you've "designed" the server you want by including the bundles and indicating that you want them started at server startup.  How is it different whether the bundles are started from startup.properties or the feature service looking at boot features?
>>>>>>>>> 
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>> 
>>>>>>>>> On Apr 16, 2011, at 11:48 AM, Johan Edstrom wrote:
>>>>>>>>> 
>>>>>>>>>> I really think that the startup.properties is for infrastructure, bluperint etc.
>>>>>>>>>> the startup features allows you do "design" your own distro.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Apr 16, 2011, at 12:42 PM, David Jencks wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hi JB,
>>>>>>>>>>> 
>>>>>>>>>>> Thanks for the explanation, I think I've looked at things from only the karaf-assembly point of view too long to see anything else :-)  The way karaf-assembly works now, all the bundles in system will be listed in startup.properties and will start automatically.
>>>>>>>>>>> 
>>>>>>>>>>> I think you are saying:
>>>>>>>>>>> 
>>>>>>>>>>> -- if you include a feature in the boot feature list, you should make sure all the bundles needed are in the server already.
>>>>>>>>>>> 
>>>>>>>>>>> and, looking more closely at the add-features-to-repo mojo I see there's a<features>  configuration element that lets you specify features to install the bundles for.
>>>>>>>>>>> 
>>>>>>>>>>> I'm going to add that capability to the karaf-assembly packaging.
>>>>>>>>>>> 
>>>>>>>>>>> There's another difference of style to resolve.  I've set up the karaf-assembly packaging so that whenever it installs a featue, it adds the feature's bundles to startup.properties at the appropriate start level.  For "boot" features this means that you don't need to list them in the features service configuration "boot features" since they will be started via the startup.properties.  On the other hand you can't uninstall this feature so easily.  Is this an important difference? Do I need to make a way to install a feature's bundles but not add the bundles to startup.properties?
>>>>>>>>>>> 
>>>>>>>>>>> many thanks
>>>>>>>>>>> david jencks
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Apr 16, 2011, at 12:12 AM, Jean-Baptiste Onofré wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Hi David,
>>>>>>>>>>>> 
>>>>>>>>>>>> I'm not sure to follow you. bootFeatures property defines which features are started at Karaf bootstrap time. It allows user to start a fresh Karaf instance with a set of Karaf features loaded and installed.
>>>>>>>>>>>> 
>>>>>>>>>>>> For instance, in ServiceMix, we have:
>>>>>>>>>>>> - nmr feature as boot feature and we ship all required jar (using features-add-to-repo goal) in the system OBR
>>>>>>>>>>>> - camel-nmr, cxf-nmr, etc are part of the NMR features but not in the boot features set. As we consider this kind of features as optional, we don't ship the features jar in the system OBR
>>>>>>>>>>>> 
>>>>>>>>>>>> Regards
>>>>>>>>>>>> JB
>>>>>>>>>>>> 
>>>>>>>>>>>> On 04/16/2011 08:32 AM, David Jencks wrote:
>>>>>>>>>>>>> I am wondering why we have boot features in trunk.  In particular I think there is an inconsistency around the management feature which is in the minimal boot feature list and whose jars are in the minimal server assembly.  On the other hand the ssh full boot feature doesn't have all its jars in the full server.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> If a boot feature doesn't already have all its jars in the server, won't this require internet access on initial startup?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> If all the jars for a boot feature are already installed in the server, why call it a boot feature, why not just start it with the rest of the jars?  For this question I may be biased by looking at the packaging based assemblies where the startup.properties is constructed from the features that are installed into the server, so it is at least as east to configure the assembly to just include the jars as to configure a boot feature.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Am I missing something?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> thanks
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>> 
>>>>>> Connect at CamelOne May 24-26
>>>>>> The Open Source Integration Conference
>>>>>> http://camelone.com/
>>> 
> 
> -- 
> Christian Schneider
> CXF and Camel Architect
> SOPERA - The Application Integration Division of Talend
> http://www.talend.com
>

Re: Please review! Re: Why boot features?

Posted by Christian Schneider <ch...@sopera.com>.

+1
For auto starting features by default

Christian


Am 19.04.2011 09:05, schrieb Achim Nierbeck:
> hm,
>
> I only have one open question, the other "standard" features like war
> and webconsole, when I install those features the bundles stay in
> installed state, and some
> of those bundles are supposed to be system bundles, e.g. the web
> console bundle. I kind of miss the standard behaviour of installing a
> feature and all bundles are up and running. How do we get around that?
> And actually the current behavior of installing a feature and those
> features are right available is one of the best things about the
> features. I'd rather like to see it the other way round.
>
> Default behavior should be the same as before, if a feature is
> installed all bundles are started right away, if I don't want it that
> way I need to add a special flag like --nostart or something.
>
> regards, Achim
>
> 2011/4/19 David Jencks<da...@yahoo.com>:
>> In r1094800 I adopted these ideas.  The biggest change to review is adding a "forceStart" option to the FeaturesService options.  This is so we can assure that all bundles in boot features get started.   I thought I remembered a -s features:install option that would start all the bundles, but it doesn't seem to be there today.  If no one objects to this enum option I think we should add the command option.
>>
>> In addition I made a new feature called "standard" in the standard features which contains the stuff from framework that can easily be installed as a boot feature.  I also made the full kar's feature installed as a boot feature.
>>
>> The servers (old and new) seem to start OK for me and have the expected content.  Please check for problems.
>>
>> thanks
>> david jencks
>>
>> On Apr 18, 2011, at 12:15 AM, David Jencks wrote:
>>
>>> I think there's a problem with boot features, and I think we don't see it with the old style assemblies because the bundles are in fact all listed in the startup.properties as well as as boot features.
>>>
>>> There are 3 bundles in other parts of the startup.properties that depend on  Apache Karaf :: Management (3.0.0.SNAPSHOT):
>>>
>>> [  14] [Installed  ] [            ] [   30] Apache Karaf :: Diagnostic :: Management (3.0.0.SNAPSHOT)
>>> [  16] [Installed  ] [            ] [   30] Apache Karaf :: Features :: Management (3.0.0.SNAPSHOT)
>>> [  19] [Installed  ] [            ] [   30] Apache Karaf :: Admin :: Management (3.0.0.SNAPSHOT)
>>>
>>> Even if I put the feature core bundle at start level 25 it installs the boot feature asynchronously so the management bundle isn't installed by the time these 3 bundles need it.
>>> I'm not 100% sure but I think this problem still occurs if I make the feature service install the boot features synchronously.  I'm surprised but can't debug through it tonight.
>>>
>>> One possible fix might be to move more of this into boot features so there are no dependencies from startup.properties-started-bundles on boot feature bundles.  This is a pretty big change to the structure of the minimal server.
>>>
>>> Also the boot features don't appear to be started by default unless I put start='true' into each bundle.
>>>
>>> Any suggestions?
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>> On Apr 17, 2011, at 12:23 PM, David Jencks wrote:
>>>
>>>> Hi Guillaume,
>>>>
>>>> I think you are suggesting:
>>>>
>>>> 1. combine local-repo and system under a suitable name such as system or repository.  I'll use system for now.
>>>>
>>>> 2. have as little as possible in startup.properties.  For instance the startup.properties for minimal and full servers should be the same
>>>>
>>>> 3. everything else in the basic minimal and full servers should be started through bootFeatures.  We want to ensure that all the required bundles are in the (single) repo.
>>>>
>>>> 4. generally to create a custom server you'll add (or maybe also remove) more bootFeatures and make sure the bundles are installed into the repo.
>>>>
>>>> This seems entirely reasonable to me.  The only quibble I can think of at the moment is that if everything is in startup.properties you can look at one file and see everything that will be started in one place.
>>>>
>>>> I'm not sure how it works right now, but with  this approach I think we'll want to make sure that when the features service starts it installs all the boot feature bundles immediately so the framework can use the start level specified in the features and the order listed in bootFeatures won't matter.
>>>>
>>>> One situation this approach won't work for is if you need some bundles started before  the feature service itself.  For instance if you want jaxb 2.2 used everywhere you'd need to install the jaxb 2.2 system with a lower start level than the feature service.  So some custom servers may need to alter the startup.properties compared to the minimal server.  While in this case I expect the jaxb 2.2 feature I'll need will be in its own feature repo so it can be handled by just listing it as a compile scope dependency, so its bundles will get added to startup.properties, this kind of situation indicates to me that startupFeatures can still be useful.
>>>>
>>>> I'll see if I run into any problems switching the new-style assemblies to this approach.
>>>>
>>>> thanks!
>>>> david jencks
>>>>
>>>>
>>>> On Apr 17, 2011, at 12:00 PM, Guillaume Nodet wrote:
>>>>
>>>>> Note that I've recently enhanced the startup mecahnism to not *always*
>>>>> try to install the bundles listed in the startup.properties.
>>>>> Previously, they were always reinstalled at startup time.
>>>>>
>>>>> First, I don't really see the need for local-repo and system.   I
>>>>> think we should just merge them.
>>>>>
>>>>> There's really no need for bootFeatures + startupFeatures.  I think we
>>>>> should only have one mechanism.    The original idea was that the core
>>>>> bundles are started with the startup.properties and everthing else
>>>>> installed using features, mostly through bootFeatures.   Now that we
>>>>> have a better maven plugin, the plugin is able to do both, but this is
>>>>> a bit confusing.   Note that there is some differences though:
>>>>> * bundles listed startup.properties have to be in the system repo as
>>>>> the real mvn url handlers can't be used
>>>>> * manually editing the statup.properties is much more tedious than
>>>>> changing the bootFeatures imho
>>>>> * you can't put bundles using wrap url handler in the startup.properties
>>>>> The third point is specially problematic I think.  One possible use
>>>>> case that isn't really addressed yet is the ability to create a
>>>>> configuration where some features depend on url handlers that are
>>>>> provisioned by other features.   Or, said another way, a feature can
>>>>> only be *installed* if a dependent feature is *started*.   I think
>>>>> moving things back in the startup.properties will make such
>>>>> dependencies even harder to manage.
>>>>>
>>>>> I think I would have rathe gone the opposite direction and remove as
>>>>> much as possible from the startup.properties to use the bootfeatures
>>>>> instead, but it may be just me.
>>>>>
>>>>> Just to understand the goal, what kind of benefit do you see by
>>>>> listing all bundles in the startup.properties ?  I suppose we could
>>>>> get rid of the features service at runtime then, but apart from that,
>>>>> I'm not sure to see.
>>>>>
>>>>> On Sun, Apr 17, 2011 at 09:41, David Jencks<da...@yahoo.com>  wrote:
>>>>>> Well, I think it may promote confusion, but there are now 3 options for features in features repositories of maven runtime scope:
>>>>>>
>>>>>> startupFeatures.  The bundles in these features will get installed into system and listed in startup.properties
>>>>>>
>>>>>> bootFeatures: The bundles in these features will get installed into local-repo and the feature names added to  bootFeatures in the features cfg file
>>>>>>
>>>>>> installedFeatures: The bundles in these features will get installed into local-repo.
>>>>>>
>>>>>> For instance,
>>>>>>
>>>>>>               <configuration>
>>>>>>                   <startupFeatures>
>>>>>>                       <feature>ssh</feature>
>>>>>>                       <feature>config</feature>
>>>>>>                       <feature>management</feature>
>>>>>>                   </startupFeatures>
>>>>>>               </configuration>
>>>>>>
>>>>>> Note that except for startupFeatures the bundles are installed into local-repo.  I think system should only have bundles started from startup.properties in it.
>>>>>>
>>>>>> thoughts?
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>> On Apr 16, 2011, at 12:50 PM, Johan Edstrom wrote:
>>>>>>
>>>>>>> For me it'd be the same logic as not "starting" everything from tomcats endorsed lib and
>>>>>>> just deploying WAR file, perhaps a little convoluted comparison, but the features additions, adding
>>>>>>> things and keeping "application" vs. features does make it simpler to manage as your features and deployments grow.
>>>>>>>
>>>>>>>
>>>>>>> On Apr 16, 2011, at 1:05 PM, David Jencks wrote:
>>>>>>>
>>>>>>>> If the same bundles all get started when you start the server, what is the difference?  I think you've "designed" the server you want by including the bundles and indicating that you want them started at server startup.  How is it different whether the bundles are started from startup.properties or the feature service looking at boot features?
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On Apr 16, 2011, at 11:48 AM, Johan Edstrom wrote:
>>>>>>>>
>>>>>>>>> I really think that the startup.properties is for infrastructure, bluperint etc.
>>>>>>>>> the startup features allows you do "design" your own distro.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Apr 16, 2011, at 12:42 PM, David Jencks wrote:
>>>>>>>>>
>>>>>>>>>> Hi JB,
>>>>>>>>>>
>>>>>>>>>> Thanks for the explanation, I think I've looked at things from only the karaf-assembly point of view too long to see anything else :-)  The way karaf-assembly works now, all the bundles in system will be listed in startup.properties and will start automatically.
>>>>>>>>>>
>>>>>>>>>> I think you are saying:
>>>>>>>>>>
>>>>>>>>>> -- if you include a feature in the boot feature list, you should make sure all the bundles needed are in the server already.
>>>>>>>>>>
>>>>>>>>>> and, looking more closely at the add-features-to-repo mojo I see there's a<features>  configuration element that lets you specify features to install the bundles for.
>>>>>>>>>>
>>>>>>>>>> I'm going to add that capability to the karaf-assembly packaging.
>>>>>>>>>>
>>>>>>>>>> There's another difference of style to resolve.  I've set up the karaf-assembly packaging so that whenever it installs a featue, it adds the feature's bundles to startup.properties at the appropriate start level.  For "boot" features this means that you don't need to list them in the features service configuration "boot features" since they will be started via the startup.properties.  On the other hand you can't uninstall this feature so easily.  Is this an important difference? Do I need to make a way to install a feature's bundles but not add the bundles to startup.properties?
>>>>>>>>>>
>>>>>>>>>> many thanks
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Apr 16, 2011, at 12:12 AM, Jean-Baptiste Onofré wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure to follow you. bootFeatures property defines which features are started at Karaf bootstrap time. It allows user to start a fresh Karaf instance with a set of Karaf features loaded and installed.
>>>>>>>>>>>
>>>>>>>>>>> For instance, in ServiceMix, we have:
>>>>>>>>>>> - nmr feature as boot feature and we ship all required jar (using features-add-to-repo goal) in the system OBR
>>>>>>>>>>> - camel-nmr, cxf-nmr, etc are part of the NMR features but not in the boot features set. As we consider this kind of features as optional, we don't ship the features jar in the system OBR
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> JB
>>>>>>>>>>>
>>>>>>>>>>> On 04/16/2011 08:32 AM, David Jencks wrote:
>>>>>>>>>>>> I am wondering why we have boot features in trunk.  In particular I think there is an inconsistency around the management feature which is in the minimal boot feature list and whose jars are in the minimal server assembly.  On the other hand the ssh full boot feature doesn't have all its jars in the full server.
>>>>>>>>>>>>
>>>>>>>>>>>> If a boot feature doesn't already have all its jars in the server, won't this require internet access on initial startup?
>>>>>>>>>>>>
>>>>>>>>>>>> If all the jars for a boot feature are already installed in the server, why call it a boot feature, why not just start it with the rest of the jars?  For this question I may be biased by looking at the packaging based assemblies where the startup.properties is constructed from the features that are installed into the server, so it is at least as east to configure the assembly to just include the jars as to configure a boot feature.
>>>>>>>>>>>>
>>>>>>>>>>>> Am I missing something?
>>>>>>>>>>>>
>>>>>>>>>>>> thanks
>>>>>>>>>>>> david jencks
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>> Connect at CamelOne May 24-26
>>>>> The Open Source Integration Conference
>>>>> http://camelone.com/
>>

-- 
Christian Schneider
CXF and Camel Architect
SOPERA - The Application Integration Division of Talend
http://www.talend.com

Re: Please review! Re: Why boot features?

Posted by Achim Nierbeck <bc...@googlemail.com>.

hm,

I only have one open question, the other "standard" features like war
and webconsole, when I install those features the bundles stay in
installed state, and some
of those bundles are supposed to be system bundles, e.g. the web
console bundle. I kind of miss the standard behaviour of installing a
feature and all bundles are up and running. How do we get around that?
And actually the current behavior of installing a feature and those
features are right available is one of the best things about the
features. I'd rather like to see it the other way round.

Default behavior should be the same as before, if a feature is
installed all bundles are started right away, if I don't want it that
way I need to add a special flag like --nostart or something.

regards, Achim

2011/4/19 David Jencks <da...@yahoo.com>:
> In r1094800 I adopted these ideas.  The biggest change to review is adding a "forceStart" option to the FeaturesService options.  This is so we can assure that all bundles in boot features get started.   I thought I remembered a -s features:install option that would start all the bundles, but it doesn't seem to be there today.  If no one objects to this enum option I think we should add the command option.
>
> In addition I made a new feature called "standard" in the standard features which contains the stuff from framework that can easily be installed as a boot feature.  I also made the full kar's feature installed as a boot feature.
>
> The servers (old and new) seem to start OK for me and have the expected content.  Please check for problems.
>
> thanks
> david jencks
>
> On Apr 18, 2011, at 12:15 AM, David Jencks wrote:
>
>> I think there's a problem with boot features, and I think we don't see it with the old style assemblies because the bundles are in fact all listed in the startup.properties as well as as boot features.
>>
>> There are 3 bundles in other parts of the startup.properties that depend on  Apache Karaf :: Management (3.0.0.SNAPSHOT):
>>
>> [  14] [Installed  ] [            ] [   30] Apache Karaf :: Diagnostic :: Management (3.0.0.SNAPSHOT)
>> [  16] [Installed  ] [            ] [   30] Apache Karaf :: Features :: Management (3.0.0.SNAPSHOT)
>> [  19] [Installed  ] [            ] [   30] Apache Karaf :: Admin :: Management (3.0.0.SNAPSHOT)
>>
>> Even if I put the feature core bundle at start level 25 it installs the boot feature asynchronously so the management bundle isn't installed by the time these 3 bundles need it.
>> I'm not 100% sure but I think this problem still occurs if I make the feature service install the boot features synchronously.  I'm surprised but can't debug through it tonight.
>>
>> One possible fix might be to move more of this into boot features so there are no dependencies from startup.properties-started-bundles on boot feature bundles.  This is a pretty big change to the structure of the minimal server.
>>
>> Also the boot features don't appear to be started by default unless I put start='true' into each bundle.
>>
>> Any suggestions?
>>
>> thanks
>> david jencks
>>
>>
>> On Apr 17, 2011, at 12:23 PM, David Jencks wrote:
>>
>>> Hi Guillaume,
>>>
>>> I think you are suggesting:
>>>
>>> 1. combine local-repo and system under a suitable name such as system or repository.  I'll use system for now.
>>>
>>> 2. have as little as possible in startup.properties.  For instance the startup.properties for minimal and full servers should be the same
>>>
>>> 3. everything else in the basic minimal and full servers should be started through bootFeatures.  We want to ensure that all the required bundles are in the (single) repo.
>>>
>>> 4. generally to create a custom server you'll add (or maybe also remove) more bootFeatures and make sure the bundles are installed into the repo.
>>>
>>> This seems entirely reasonable to me.  The only quibble I can think of at the moment is that if everything is in startup.properties you can look at one file and see everything that will be started in one place.
>>>
>>> I'm not sure how it works right now, but with  this approach I think we'll want to make sure that when the features service starts it installs all the boot feature bundles immediately so the framework can use the start level specified in the features and the order listed in bootFeatures won't matter.
>>>
>>> One situation this approach won't work for is if you need some bundles started before  the feature service itself.  For instance if you want jaxb 2.2 used everywhere you'd need to install the jaxb 2.2 system with a lower start level than the feature service.  So some custom servers may need to alter the startup.properties compared to the minimal server.  While in this case I expect the jaxb 2.2 feature I'll need will be in its own feature repo so it can be handled by just listing it as a compile scope dependency, so its bundles will get added to startup.properties, this kind of situation indicates to me that startupFeatures can still be useful.
>>>
>>> I'll see if I run into any problems switching the new-style assemblies to this approach.
>>>
>>> thanks!
>>> david jencks
>>>
>>>
>>> On Apr 17, 2011, at 12:00 PM, Guillaume Nodet wrote:
>>>
>>>> Note that I've recently enhanced the startup mecahnism to not *always*
>>>> try to install the bundles listed in the startup.properties.
>>>> Previously, they were always reinstalled at startup time.
>>>>
>>>> First, I don't really see the need for local-repo and system.   I
>>>> think we should just merge them.
>>>>
>>>> There's really no need for bootFeatures + startupFeatures.  I think we
>>>> should only have one mechanism.    The original idea was that the core
>>>> bundles are started with the startup.properties and everthing else
>>>> installed using features, mostly through bootFeatures.   Now that we
>>>> have a better maven plugin, the plugin is able to do both, but this is
>>>> a bit confusing.   Note that there is some differences though:
>>>> * bundles listed startup.properties have to be in the system repo as
>>>> the real mvn url handlers can't be used
>>>> * manually editing the statup.properties is much more tedious than
>>>> changing the bootFeatures imho
>>>> * you can't put bundles using wrap url handler in the startup.properties
>>>> The third point is specially problematic I think.  One possible use
>>>> case that isn't really addressed yet is the ability to create a
>>>> configuration where some features depend on url handlers that are
>>>> provisioned by other features.   Or, said another way, a feature can
>>>> only be *installed* if a dependent feature is *started*.   I think
>>>> moving things back in the startup.properties will make such
>>>> dependencies even harder to manage.
>>>>
>>>> I think I would have rathe gone the opposite direction and remove as
>>>> much as possible from the startup.properties to use the bootfeatures
>>>> instead, but it may be just me.
>>>>
>>>> Just to understand the goal, what kind of benefit do you see by
>>>> listing all bundles in the startup.properties ?  I suppose we could
>>>> get rid of the features service at runtime then, but apart from that,
>>>> I'm not sure to see.
>>>>
>>>> On Sun, Apr 17, 2011 at 09:41, David Jencks <da...@yahoo.com> wrote:
>>>>> Well, I think it may promote confusion, but there are now 3 options for features in features repositories of maven runtime scope:
>>>>>
>>>>> startupFeatures.  The bundles in these features will get installed into system and listed in startup.properties
>>>>>
>>>>> bootFeatures: The bundles in these features will get installed into local-repo and the feature names added to  bootFeatures in the features cfg file
>>>>>
>>>>> installedFeatures: The bundles in these features will get installed into local-repo.
>>>>>
>>>>> For instance,
>>>>>
>>>>>              <configuration>
>>>>>                  <startupFeatures>
>>>>>                      <feature>ssh</feature>
>>>>>                      <feature>config</feature>
>>>>>                      <feature>management</feature>
>>>>>                  </startupFeatures>
>>>>>              </configuration>
>>>>>
>>>>> Note that except for startupFeatures the bundles are installed into local-repo.  I think system should only have bundles started from startup.properties in it.
>>>>>
>>>>> thoughts?
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> On Apr 16, 2011, at 12:50 PM, Johan Edstrom wrote:
>>>>>
>>>>>> For me it'd be the same logic as not "starting" everything from tomcats endorsed lib and
>>>>>> just deploying WAR file, perhaps a little convoluted comparison, but the features additions, adding
>>>>>> things and keeping "application" vs. features does make it simpler to manage as your features and deployments grow.
>>>>>>
>>>>>>
>>>>>> On Apr 16, 2011, at 1:05 PM, David Jencks wrote:
>>>>>>
>>>>>>> If the same bundles all get started when you start the server, what is the difference?  I think you've "designed" the server you want by including the bundles and indicating that you want them started at server startup.  How is it different whether the bundles are started from startup.properties or the feature service looking at boot features?
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>> On Apr 16, 2011, at 11:48 AM, Johan Edstrom wrote:
>>>>>>>
>>>>>>>> I really think that the startup.properties is for infrastructure, bluperint etc.
>>>>>>>> the startup features allows you do "design" your own distro.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Apr 16, 2011, at 12:42 PM, David Jencks wrote:
>>>>>>>>
>>>>>>>>> Hi JB,
>>>>>>>>>
>>>>>>>>> Thanks for the explanation, I think I've looked at things from only the karaf-assembly point of view too long to see anything else :-)  The way karaf-assembly works now, all the bundles in system will be listed in startup.properties and will start automatically.
>>>>>>>>>
>>>>>>>>> I think you are saying:
>>>>>>>>>
>>>>>>>>> -- if you include a feature in the boot feature list, you should make sure all the bundles needed are in the server already.
>>>>>>>>>
>>>>>>>>> and, looking more closely at the add-features-to-repo mojo I see there's a <features> configuration element that lets you specify features to install the bundles for.
>>>>>>>>>
>>>>>>>>> I'm going to add that capability to the karaf-assembly packaging.
>>>>>>>>>
>>>>>>>>> There's another difference of style to resolve.  I've set up the karaf-assembly packaging so that whenever it installs a featue, it adds the feature's bundles to startup.properties at the appropriate start level.  For "boot" features this means that you don't need to list them in the features service configuration "boot features" since they will be started via the startup.properties.  On the other hand you can't uninstall this feature so easily.  Is this an important difference? Do I need to make a way to install a feature's bundles but not add the bundles to startup.properties?
>>>>>>>>>
>>>>>>>>> many thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Apr 16, 2011, at 12:12 AM, Jean-Baptiste Onofré wrote:
>>>>>>>>>
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> I'm not sure to follow you. bootFeatures property defines which features are started at Karaf bootstrap time. It allows user to start a fresh Karaf instance with a set of Karaf features loaded and installed.
>>>>>>>>>>
>>>>>>>>>> For instance, in ServiceMix, we have:
>>>>>>>>>> - nmr feature as boot feature and we ship all required jar (using features-add-to-repo goal) in the system OBR
>>>>>>>>>> - camel-nmr, cxf-nmr, etc are part of the NMR features but not in the boot features set. As we consider this kind of features as optional, we don't ship the features jar in the system OBR
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> JB
>>>>>>>>>>
>>>>>>>>>> On 04/16/2011 08:32 AM, David Jencks wrote:
>>>>>>>>>>> I am wondering why we have boot features in trunk.  In particular I think there is an inconsistency around the management feature which is in the minimal boot feature list and whose jars are in the minimal server assembly.  On the other hand the ssh full boot feature doesn't have all its jars in the full server.
>>>>>>>>>>>
>>>>>>>>>>> If a boot feature doesn't already have all its jars in the server, won't this require internet access on initial startup?
>>>>>>>>>>>
>>>>>>>>>>> If all the jars for a boot feature are already installed in the server, why call it a boot feature, why not just start it with the rest of the jars?  For this question I may be biased by looking at the packaging based assemblies where the startup.properties is constructed from the features that are installed into the server, so it is at least as east to configure the assembly to just include the jars as to configure a boot feature.
>>>>>>>>>>>
>>>>>>>>>>> Am I missing something?
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>> Connect at CamelOne May 24-26
>>>> The Open Source Integration Conference
>>>> http://camelone.com/
>>>
>>
>
>