Hi Carsten I did this change: https://github.com/retobg/sling-stanbol/commit/802bc84f5fbac081b911e6588a90b8de170c3974
Unfortunately the results are the same as before: - the JerseyEndpoint gets configured at / - The sling engine cannot start because / is already taken - the JerseyEndpoint is reconfigured to run at /stanbol as per the configuration When stopping the app and starting it again things works. Cheers, Reto On Tue, Jul 17, 2012 at 1:24 AM, Carsten Ziegeler <[email protected]>wrote: > Hi Reto, > > you can put config files into "src/main/config" in your launchpad > project and these configurations are included in your launchpad and > get applied on startup as soon as possible. > > Regards > Carsten > > 2012/7/16 Reto Bachmann-Gmür <[email protected]>: > > Thanks Carsten, > > > > Not sure what configuring like I do with bundles means. Could you give > me a > > pointer? > > > > Cheers, > > Reto > > > > On Mon, Jul 16, 2012 at 2:58 AM, Carsten Ziegeler <[email protected] > >wrote: > > > >> 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] > >> > > > > -- > Carsten Ziegeler > [email protected] >
