I stand corrected. Thanks for that ;-) Regards Felix
Am 19.08.2013 um 08:30 schrieb David Jencks: > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
