Hi Felix
Thanks for your reply.
Normally when configuration is available before the component is activated,
> it is activated with the configuration. If the configuration only becomes
> available later, the component is potentially reactivated with the
> configuration (potentially because the component may be declared to take
> configuration through a modified method).
>
I guess the reason is that org.apache.sling.launchpad.installer has a
higher startlevel than the bundle being configured.
Could you give me a hint on how I can increase the startLevel using rules?
I've tried:
rule "increase stanbol level"
when
$bundleList : BundleList()
$startLevel : StartLevel() from $bundleList.startLevels
$bundle : Bundle(groupId == "org.apache.stanbol")
from $startLevel.bundles
then
System.out.println("increasing:" + $bundle.getArtifactId()+"
original: "+$bundle.getStartLevel());
$bundle.setStartLevel($bundle.getStartLevel()+10);
end
>
> > As a consequence my app [1]
> > doesn't work correctly when started the first time. From the second start
> > up it works correctly as it doesn't first start the component with the
> > wrong configuration.
> >
> > Is there a way to make sure the components aren't started without the
> > provided configuration?
>
> Yes, you can declare the component to require component. Such components
> are only activated once configuration is available. As soon as the
> configuration is removed, the component is deactivated.
>
> Look for the "configuration policy" attribute.
>
If I understand correctly this would require modifying the bundle
containing the component needing the configuration, in this project however
I would like to just distribute the existing bundles without modifications.
Cheers,
Reto