Another problem with features that we install the bundles for is that we end up with 2 copies of all the bundles: one in the system repo and one copy in the osgi framework.
When installing a feature bundle do we want to check the system repo for it and use a reference: url if found? 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/ >> >
