[
https://issues.apache.org/jira/browse/ARIES-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13565543#comment-13565543
]
Guillaume Nodet commented on ARIES-1010:
----------------------------------------
I think registering a BlueprintEventListener as an OSGi service should provide
you the needed BlueprintEvents.
> BlueprintContainer - reload() - no way to know when the reload is fully done
> ----------------------------------------------------------------------------
>
> Key: ARIES-1010
> URL: https://issues.apache.org/jira/browse/ARIES-1010
> 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: http://www.atlassian.com/software/jira
