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 <[email protected]>: > 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<[email protected]>: >>>> 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<[email protected]> >>>>>>> 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 >> > >
