karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [Discuss] Handling of initial bundles
Date Tue, 08 May 2012 15:49:01 GMT
I really don't understand what problem you are trying to solve.  Most people won't use a custom
assembly or if they do will use the same startup.properties as our assemblies.  Anyone who
needs to construct a custom set of startup bundles isn't going to be worried by the startup.properties
format, that is a tiny detail compared with figuring out what you need to get a working server
from startup bundles.

I agree with Guillaume that keeping the startup code simple is a very high priority.  To me,
adding anything that involves xml to the startup code is a really bad idea and would require
very clear and overwhelming advantages to be considered.

I've never suggested reading more than one feature during startup.  I think the current approach
of generating startup.properties from features specified in the assembly's pom is just fine.

david jencks

On May 8, 2012, at 12:01 AM, Christian Schneider wrote:

> I would like to summarize the discussion about my proposed second step to replace the
startup.properties by a feature loading. Again sorry that I committed the first part too early.
> I think though that our discussion mainly was about the second part and I did not even
start to implement that.
> Here the requirements people wrote during the discussion:
> - We should not introduce additional dependencies into the main module
> - Some people like the startup.properties. So we should keep this feature
> - In addition to the maven urls we should also support loading bundles from a flat directory
> - We should allow several features from several feature files to be used at startup
> So this is what I propose to fullfill the above requirements:
> - If a startup.properties file exists then the bundles in there will be loaded and started
(works already)
> - We introduce two new optional properties for config.properties: startup.feature.url
and startup.feature.name (default:framework)
> - If the startup.feature.url property is present then we resolve the startup.feature.url
using the ArtifactResolver and read the named feature. We then install all bundles in the
> feature with their corresponding startlevels
> - We allow to use file names in the startup.properties that are searched in system and
bundle.locations. This allows the flat structure. (Works already)
> - We read the feature file using jaxb but not with the feaure service. Instead we simply
use annotated pojos
> - We switch the build process of our framework feature to not generate the startup.properties
anymore and instead use the new properties to reference the existing
> feature
> - I propose to not implement the possibility to use more than one feature in the startup
as this feature is only used to bootstrap the distro. I dont think custom distros need to
change that behaviour
> Pro:
> - Makes our build simpler
> - Makes our itests simpler as we do not need to sync the startup.properties anymore by
> - People who already know the feature concept do not have to learn the new concept of
the startup.properties
> Con:
> - We have an additional description of a feature file in main. I think this is not so
bad as we keep it to the minimum. We should also detect discrepancies very fast as the
> itests will fail
> Christian
> Am 04.05.2012 19:03, schrieb Christian Schneider:
>> Hi all,
>> on startup we currently use the following procedure.
>> We read property karaf.auto.start from the file config.properties.
>> This can be either a list of bundles separated by spaces or "startup.properties"
or "all".
>> If it is all we replace karaf.auto.start with the list of all bundles in the system
dir. I think this option does not really make much sense.
>> If it is startup.properties then we replace karaf.auto.start with the list of bundles
specified in the file startup.properties.
>> Additionally we either support mvn urls or paths which are converted to mvn urls.
>> This all is quite a lot of variability of which we use none.
>> I propose to replace this in two steps:
>> 1. Remove the karaf.auto.start property and always load the bundles from startup.properties.
Also only support mvn urls.
>> This makes the code in main cleaner and makes it easier for our users to understand
how to change the startup bundles.
>> 2. Remove the startup.properties and instead use a feature name to determine the
list of bundles to load
>> The second step makes this even simpler and additionally we can remove the generation
of the startup.properties in the karaf maven plugin.
>> So what do you think?
>> Christian
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> Open Source Architect
> Talend Application Integration Division http://www.talend.com

View raw message