felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: DS and Exceptions
Date Mon, 19 Aug 2013 13:29:41 GMT
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 <fmeschbe@adobe.com> 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: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message