Hi, if you provide your configuration through launchpad (like you do with bundles), the configuration should be installed as early as possible and therefore be available when your service is started. You could try fiddling around with start levels, setting the start level of a bundle depends on how you install it. Using the Sling installer, put it into a sub folder with the start level as the folder name, or if you use the bundle list, create a section with the start level.
In general, the component you're using should cope with the configuration arriving at any time. For example, the component might be started before config admin or anything else is done in a different order than "usual". Or the configuration is changed. In OSGi everything is dynamic and can come and go, so implementations should handle this fact. Regards Carsten 2012/7/16 Reto Bachmann-Gmür <[email protected]>: > 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 -- Carsten Ziegeler [email protected]
