blueprint deployer and spring deployer should get started before features.core bundle

Details

Type: Improvement

Status:Resolved

Priority: Major

Resolution:
Won't Fix

Affects Version/s:
None

Fix Version/s:
None

Component/s:
None

Labels:

None

Description

When org.apache.karaf.features.core bundle is up, it will load features descriptors and try install features, however if the features descriptor has bundle like
<bundle>blueprint:file:etc/some-blueprint.xml</bundle>, we need blueprint url handler available in the OSGi container, so we need blueprint deployer and spring deployer get started before features.core bundle

Yes .. but then we depend on the handlers .. I would like to find a solution that can work with unknown handlers too. Basically the idea is to first load bundles that do not need the handlers. We then need to start at least the bundles with the handlers before starting the rest. The problem is that there is no way to see if a bundle contains a handler from the outside. So I am not sure how to achieve it.

Christian Schneider
added a comment - 24/Sep/12 08:41 Yes .. but then we depend on the handlers .. I would like to find a solution that can work with unknown handlers too. Basically the idea is to first load bundles that do not need the handlers. We then need to start at least the bundles with the handlers before starting the rest. The problem is that there is no way to see if a bundle contains a handler from the outside. So I am not sure how to achieve it.

I think the feature install now waits for some time for missing url handlers. Does this fix the problem? I am also working on parallelizing the install of bundles. This will help if the url handler appear after a bundle they should install. See kARAf-608. I will explain what I have in mind there shortly.

Christian Schneider
added a comment - 23/Sep/12 18:59 I think the feature install now waits for some time for missing url handlers. Does this fix the problem? I am also working on parallelizing the install of bundles. This will help if the url handler appear after a bundle they should install. See kARAf-608. I will explain what I have in mind there shortly.

Ioannis Canellos
added a comment - 11/Sep/12 16:23 I am reopening the issue, because I feel that the features service should not depend on deployers of any short.
Moreover, the current solution may solve the problem for blueprint and spring url handlers, but still doesn't address the case where the user wants to use a custom url handler.

Jean-Baptiste Onofré
added a comment - 09/Mar/12 08:46 Nevermind, the deployers should be in the startup.properties, else the features.core will always be started before.
I move the deployers into the startup.properties.

On Karaf 3.0, the blueprint/spring deployer isn't in startup.properties, they're in deployer feature description, so unless we also pull blueprint/spring deployer bundles into startup.properties, there's no way we can guarantee that they get started before features.core bundle.
I'm +1 to put blueprint/spring deployer bundles into startup.properties, it's easier for end user when they have features which need blueprint/spring url handler.

Freeman Fang
added a comment - 09/Mar/12 07:52 Hi JB,
On Karaf 3.0, the blueprint/spring deployer isn't in startup.properties, they're in deployer feature description, so unless we also pull blueprint/spring deployer bundles into startup.properties, there's no way we can guarantee that they get started before features.core bundle.
I'm +1 to put blueprint/spring deployer bundles into startup.properties, it's easier for end user when they have features which need blueprint/spring url handler.
Freeman