If you are looking for a means to specify an application exception on a
method level, then I can agree with a proposal.
In other words it should be possible for a bean developer to designate
for example PersistenceException as an application exception for certain
methods. (A throws clause alone would not be sufficient as it can not
designate the rollback attribute.)
For retaining the SFSB on system exceptions I side with Linda's
comments, but allowing explicit retention on system exceptions could be
considered as an expert user option. Then again we would be undermining
the very clear exception handling model we have on EJBs.
Carlo
On 12/21/2012 12:56 AM, Marina Vatkina wrote:
> And while you are thinking about your reply, please also look at the
> following options:
>
> 1. Applying the new option at the bean class (i.e. as a @Stateful
> attribute)
>
> 2. Applying the new option at the method-level only (i.e. as a
> separate annotation)
>
> 3. Both.
>
> thanks,
> -marina
>
> On 12/17/12 11:12 AM, Marina Vatkina wrote:
>> Experts,
>>
>> I'd like to hear opinions from more of you.
>>
>> thanks,
>> -marina
>>
>> On 12/14/12 11:18 AM, Marina Vatkina wrote:
>>> On 12/14/12 8:58 AM, Linda DeMichiel wrote:
>>>>
>>>> The rationale for destroying the bean is that it may be in an
>>>> inconsistent state and thus not safely useable (i.e, use might result
>>>> in data corruption, etc.)
>>>
>>> It still holds all of it state after the exception. And e.g. the
>>> state after a failed transaction can be verified and operation
>>> retried or the specific cause of the failed commit can be reported.
>>>
>>>>
>>>> The point of application exceptions is that they are designed for
>>>> cases that the application should be able to handle. This proposal,
>>>> if I am understanding it correctly, seems to suggest that system
>>>> exceptions
>>>> be treated as application exceptions.
>>>
>>> You can't convert a PersistenceException or a
>>> TransactionRolledBackException to an AE using annotations, and
>>> marking them in the ejb-jar.xml will apply to all beans in the same
>>> module.
>>>
>>>> I think that is the wrong thing
>>>> to do.
>>>>
>>>> On 12/13/2012 2:21 PM, Marina Vatkina wrote:
>>>>> Experts,
>>>>>
>>>>> I was looking at comments for
>>>>> http://java.net/jira/browse/EJB_SPEC-24 and one of the issues
>>>>> listed is that a SFSB is
>>>>> destroyed by the container if a business method throws a system
>>>>> exception (see section "4.6.3Dealing with Exceptions" in
>>>>> the latest version of the spec). I have seen many questions from
>>>>> the users that are surprised by one of the
>>>>> NoSuchXXXExceptions. It can also be an issue if a SFSB can be used
>>>>> as a websocket endpoint (I'm discussing with the
>>>>> websockets spec lead if it's possible).
>>>>>
>>>>> We can easily solve this problem by adding a global
>>>>> 'retainIfException' flag as an attribute on a @Stateful annotation
>>>>> (and a corresponding DD). If added, the default will be false for
>>>>> backward compatibility, and the
>>>>> @Remove(retainIfException) will override the bean level setting,
>>>>> if any.
>>>>>
>>>>> Please vote yes/no on the following 3 items:
>>>>>
>>>>> 1) we should add the bean-level retainIfException flag to SFSB
>>>>>
>>>>
>>>> Definitely not
>>>>
>>>>> 2) if added, the flag should apply to the business methods only (I
>>>>> think so - only PrePassivate might be considered, but
>>>>> it would make everything too complicated, and we've already added
>>>>> passivationCapable=false to avoid passivation altogether)
>>>>>
>>>>
>>>> No
>>>>
>>>>> 3) if you agree with 2), should the flag be called
>>>>> 'retainIfBusinessMethodException' to avoid confusion?
>>>>>
>>>>> thanks,
>>>>> -marina
>>>>>
>>>
>>
>