aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] [Resolved] (ARIES-1010) BlueprintContainer - reload() - no way to know when the reload is fully done
Date Wed, 30 Jan 2013 10:13:12 GMT


Claus Ibsen resolved ARIES-1010.

    Resolution: Won't Fix

Okay just by registering yourself as a BlueprintListener as a service, causes the blueprint
container to send the events to you - also for reload.

        registration = bundleContext.registerService(BlueprintListener.class, this, null);

You can just have a empty implementation of the callback
    public void blueprintEvent(BlueprintEvent event) {
        // noop as we just needed to enlist the BlueprintListener to have events triggered
to serviceChanged method
> BlueprintContainer - reload() - no way to know when the reload is fully done
> ----------------------------------------------------------------------------
>                 Key: ARIES-1010
>                 URL:
>             Project: Aries
>          Issue Type: Improvement
>          Components: Blueprint
>    Affects Versions: 1.0
>            Reporter: Claus Ibsen
>            Priority: Critical
> If you have a blueprint application deploy in felix / karaf. Then you can restart the
bundle from karaf shell using
> {code}
> osgi:restart 123
> {code}
> Where 123 is the bundle id. This works fine, as it does a fully restart.
> If you want to be notified about the starting|stopping in your blueprint application,
you can use the org.osgi.framework.ServiceListener and listen for changes, and wait for the
BlueprintContainer itself to be created/unregistered. For example we use this in Camel to
know when we can start Camel after all the osgi blueprint has been fully started:
> We have an init method in a POJO that we ensure blueprint invokes. This allows us to
register our service listener. 
> {code}
>     public void init() throws Exception {
>         LOG.trace("init {}", this);
>         // add service listener so we can be notified when blueprint container is done
>         // and we would be ready to start CamelContext
>         bundleContext.addServiceListener(this);
>     }
> {code}
> Where we listen for the blueprint container to be created, and invoke the maybeStart
method which will start Camel.
> {code}
>     @Override
>     public void serviceChanged(ServiceEvent event) {
>         if (LOG.isDebugEnabled()) {
>             LOG.debug("Service {} changed to {}", event, event.getType());
>         }
>         // look for blueprint container to be registered, and then we can start the CamelContext
>         if (event.getType() == ServiceEvent.REGISTERED && event.getServiceReference().isAssignableTo(bundleContext.getBundle(),
>                 "org.osgi.service.blueprint.container.BlueprintContainer")) {
>             try {
>                 maybeStart();
>             } catch (Exception e) {
>                 LOG.error("Error occurred during starting Camel: " + this + " due " +
e.getMessage(), e);
>             }
>         }
>     }
> {code}
> However if you use the API on ExtendedBlueprintContainer, which is the {{reload()}} method
then it does *not* work the same as the reload command above.
> The issue is in particular that we do not get any service listener callbacks. So we cannot
know when the blueprint container has been fully restarted.
> On the ExtendedBlueprintContainer there is no API either to get the state, eg a getState
method. If we had that we could potentially "work around" this by having to wait for the state
to be changed to CREATED.
> I am not sure if a reload should trigger the BlueprintContainer service to be unregistered/registered
again. Which will fix this for all people. As then a reload works just as stop|start a bundle.
> An alternative is that we get some API in blueprint so we can know when the reload is
done. And it would also be nice to have the getState method on the ExtendedBlueprintContainer.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message