Claus Ibsen created ARIES-1010:
----------------------------------
Summary: 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
