On Aug 18, 2013, at 10:57 PM, Felix Meschberger <[email protected]> wrote:
> Hi > > Am 18.08.2013 um 11:33 schrieb bokie: > >> Hi, >> >> Considering the internals of the SCR, what would be the most appropriate >> behaviour for a component's activate, deactivate and modified methods if an >> exception occurs: > > This really depends on how you want your component to behave: > >> i) add a throws declaration and let the SCR caller handle it or at least be >> aware of the exception > > The DS runtime will catch Exceptions from activate, deactivate, and modified > methods and log them. If the activate method throws, the component is > actually deactivated again. An exception on the modified method is > essentially just logged and further ignored (IIRC). An exception on the > deactivate method, of course, is just logged and the component is being > deactivated. > > >> ii) catch the exception within a try/catch block, maybe do some logging, but >> essentially fail silently where the SCR is concerned. > > If your component is able to operate even after encountering an exception, > this is probably the best thing you can do and which I would in fact > recommend: > > * In your activate method, you can handle any problematic situation during > activation. If you can properly handle and still operate, catch and log the > problem. Otherwise rethrow and have the component remain deactivated. The > drawback of throwing is, that it will only be activated again on bundle > restart or if an event such as a reference change or configuration change > happens causing the component to be activated again. This is no longer true in trunk. I couldn't find any support for this behavior in the spec. The component instance is discarded but the component state remains registered and another request for the service will result in another attempt to create the instance. thanks david jencks > > * In your modified method, I strongly suggest to properly handle exceptions > and make sure the component can still operate, e.g. by falling back to some > default configuration. If it cannot, I suggest to deactivate the component > through the component's ComponentContext. > > * In your deactivate method, I suggest to catch and log problems just for > your own sanity and for reasons of defensive programming such as proper > cleanup if needed (e.g. closing files, etc) > > Hope this helps. > > Regards > Felix > >> >> Regards, >> Jorge >> >> >> >> >> -- >> View this message in context: >> http://apache-felix.18485.x6.nabble.com/DS-and-Exceptions-tp5004599.html >> Sent from the Apache Felix - Users mailing list archive at Nabble.com. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
