[
https://issues.apache.org/jira/browse/ARIES-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13565349#comment-13565349
]
Claus Ibsen commented on ARIES-1010:
------------------------------------
Just to try it out I modified the reload method in the BlueprintContainerImpl
on the trunk code. And forced the BlueprintContainer to be unregistered first.
Then the reload works as if you stop and start the bundle.
See the // TODO: hack
If we unregister the registration and set it to null afterwards, then the
BlueprintContainerImpl will automatic register itself when its been created.
{code}
public void reload() {
LOGGER.debug("Reloading Bundle {}", getBundle().getSymbolicName());
synchronized (scheduled) {
if (destroyed.get()) {
return;
}
// TODO: hack need to register BlueprintContainer
if (registration != null) {
LOGGER.debug("Hack to unregister registration");
AriesFrameworkUtil.safeUnregisterService(registration);
registration = null;
}
tidyupComponents();
this.componentDefinitionRegistry.reset();
this.repository = null;
this.processors = new ArrayList<Processor>();
timeout = 5 * 60 * 1000;
waitForDependencies = true;
xmlValidation = true;
if (handlerSet != null) {
handlerSet.removeListener(this);
handlerSet.destroy();
handlerSet = null;
}
state = State.Unknown;
schedule();
}
}
{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
