-
1. Re: Exception handling in PackageAdmin.refresh(...)
bosschaert Sep 2, 2010 6:08 AM (in response to thomas.diesler)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 exceptionIt 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?
-
2. Re: Exception handling in PackageAdmin.refresh(...)
thomas.diesler Sep 6, 2010 5:07 AM (in response to bosschaert)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.