You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Reto Bachmann-Gmür <re...@apache.org> on 2012/07/15 18:51:50 UTC
how to make sure a bundle is configured before it is first startes
Hello
In my app I'm configuring a service with a bundle providing its
configuration. Now it seems the components are first started without that
configuration and then restarted with it. 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?
Cheers,
Reto
1. sling-stanbol-launcher in https://github.com/retobg/sling-stanbol
Re: how to make sure a bundle is configured before it is first startes
Posted by Reto Bachmann-Gmür <re...@apache.org>.
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 <cz...@apache.org>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 <re...@apache.org>:
> > 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 <cziegeler@apache.org
> >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 <re...@apache.org>:
> >> > 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
> >> cziegeler@apache.org
> >>
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
Re: how to make sure a bundle is configured before it is first startes
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <re...@apache.org>:
> 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 <cz...@apache.org>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 <re...@apache.org>:
>> > 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
>> cziegeler@apache.org
>>
--
Carsten Ziegeler
cziegeler@apache.org
Re: how to make sure a bundle is configured before it is first startes
Posted by Reto Bachmann-Gmür <re...@apache.org>.
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 <cz...@apache.org>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 <re...@apache.org>:
> > 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
> cziegeler@apache.org
>
Re: how to make sure a bundle is configured before it is first startes
Posted by Reto Bachmann-Gmür <re...@apache.org>.
Hi,
As the other options seem t fail I think I have to fail back to the
fiddling with the startlevels variant
On Mon, Jul 16, 2012 at 2:58 AM, Carsten Ziegeler <cz...@apache.org>wrote:
> 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.
>
As the bundles that need to get a new start-level are part of partial
bundle lists I think I should change the levels with rules. Any
hint/example on how I could do this? I already pasted what 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
Cheers,
Reto
Re: how to make sure a bundle is configured before it is first startes
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <re...@apache.org>:
> 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
cziegeler@apache.org
Re: how to make sure a bundle is configured before it is first startes
Posted by Reto Bachmann-Gmür <re...@apache.org>.
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
Re: how to make sure a bundle is configured before it is first
startes
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 15.07.2012 um 18:51 schrieb Reto Bachmann-Gmür:
> Hello
>
> In my app I'm configuring a service with a bundle providing its
> configuration. Now it seems the components are first started without that
> configuration and then restarted with it.
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).
> 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.
Regards
Felix
>
> Cheers,
> Reto
>
> 1. sling-stanbol-launcher in https://github.com/retobg/sling-stanbol