[
https://issues.apache.org/jira/browse/ARIES-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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.
{code}
registration = bundleContext.registerService(BlueprintListener.class,
this, null);
{code}
You can just have a empty implementation of the callback
{code}
@Override
public void blueprintEvent(BlueprintEvent event) {
// noop as we just needed to enlist the BlueprintListener to have
events triggered to serviceChanged method
}
{code}
> 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
