You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by bokie <jm...@gmail.com> on 2013/08/18 11:33:12 UTC
DS and Exceptions
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:
i) add a throws declaration and let the SCR caller handle it or at least be
aware of the exception
ii) catch the exception within a try/catch block, maybe do some logging, but
essentially fail silently where the SCR is concerned.
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
Re: DS and Exceptions
Posted by Felix Meschberger <fm...@adobe.com>.
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 <fm...@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
Re: DS and Exceptions
Posted by David Jencks <da...@gmail.com>.
On Aug 18, 2013, at 10:57 PM, Felix Meschberger <fm...@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
Re: DS and Exceptions
Posted by Felix Meschberger <fm...@adobe.com>.
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.
* 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