Exception handling in PackageAdmin.refresh(...)

[thomas.diesler]

Looking at http://github.com/jbosgi/jbosgi-container/commit/17e5c665a9ead847f46cd583f499317847c521a1 the exception handling has changed such that RuntimeExceptions no longer cause the refresh operation to fail.

RuntimeExceptions are usually something you cannot be recovered from and in most cases it is unresonable to continue after them. In case of package refresh the logic is now such that the sequence of stop-refresh-start is executed regardless of a potential failure in a previous step. Is this correct?

[bosschaert]

It's a good point, but basically what we're doing here is calling into 'alien' code as the starting and stopping of bundles will trigger bundle activator code and you never know what's happening in there.

The question is really: when one of the bundles that is being refreshed throws a runtime exception, should this abort the refresh operation completely (leaving the system in a half-refreshed state) or should it attempt a best effort and continue refreshing the remaining bundles?

The spec isn't very specific in this case it just says in 7.5.3.11:

For any exceptions that are thrown during any of these steps, a FrameworkEvent
of type ERROR is fired containing the exception

It doesn't really say wether or not to continue processing the remainder of the bundles.

So in this case I'm protecting the other bundles from a badly behaving bundle by logging anything that is being thrown during the stopping and restarting of it, while continuing to refresh the remainder of the bundles.

Would you suggest different behaviour?

[thomas.diesler]

We said that resolve operations are permitted to run concurrently. Once they are finished they update the framework with their respective results in an atomic operation. For this to work, the ResolverPlugin must make a copy of the XModule state and do its work on that copy. If there is a problem during these operations the ResolverPlugin state is not updated. Resolve should not be allowed to put the framework in an incosistent state.

So, if after refresh a bundle fails to start because it cannot get resolved. Should we attempt to start the remaining bundles? You are probalby right - we should. However, I'm not so sure about Errors. Perhaps we should catch Exceptions rather than Throwables.