Hi,
The point is that the way we actually use application exceptions is quite
painful in the real life. If the bean provider defines an exception, he can
easily set it as application exception so the bean is not discarded.
But, it's done once for the whole application whereas the user usually
wants to be able to decide for a specific bean or method.
When dealing with predefined runtime sub classes (PersistenceException, and
so one), the user can only declare it in ejb-jar.xml file but again for the
whole application.
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.
It would be better to think the other way, I mean:
1. keep the application exception behavior as today when the annotation is
applied on the exception (same with ejb-jar.xml file)
2. add the ability to specify for one bean and for one method which
exception must be treated as an application exception
@ApplicationException(Persistence.class) // the rollback attribute is
still useful sometimes
private class MyBean {
@ApplicationException({MyRuntimeException.class, MyOtherException.class})
public void myMthd () {
}
}
That way, you can chose when you want an exception to be an application
exception or not without defining it for the whole application which
usually means (as far I saw in project), a huge and tricky exception
hierarchy just to have a finer exception handling.
BTW, would be great to being able to add a list of exceptions. Maybe the
Query/Queries pattern is better.
Jean-Louis
2013/1/12 Marina Vatkina <marina.vatkina_at_oracle.com>
>
>
> Experts,
>
> Let's return to this discussion...
>
> I got this request from the Java API for Web Sockets spec lead, Danny
> Coward:
>
> ==============================**==
> Request to relax restriction on destroying instances of Stateful Session
> Beans:
>
> However, the current EJB specification places the limitation that the
> container must remove any instance of a stateful session bean instance if
> an invocation to one of its methods generates a runtime exception. This is
> a problem for webscket developers because it is integral to the websocket
> model that runtime errors arising from, for example, failures to parse
> particular incoming websocket messages, can explicitly be handled by the
> websocket instance, and the websocket instance continue to operate.
> example, in the Java WebSocket API, we have an annotation called
> @WebSocketError that allows the developer to mark a particular method able
> to process any such errors thrown as the methods on a websocket endpoint
> instance are called, and the websocket to continue operation on the same
> connection once the error has been properly handled."
>
> We would like the EJB specification not to require instances of websockets
> written as stateful session beans to be removed should any of the websocket
> instances methods generate runtime exceptions. Ideally, this would be
> achieved by explicitly defining this 'relaxed' behavior in the special case
> of websockets as stateful session beans, but perhaps we could live with the
> EJB spec giving us a new annotation that would 'turn off' removal of the
> instance in these cases, and that we would require websocket developers use
> when using stateful session beans."
> ==============================**==
>
> When I asked Danny about method-level vs. bean-level annotations, his
> response was:
>
> " the websocket model is to handle errors thrown on any annotated method,
> so I think, for us, the bean level is both adequate and less error prone
> (should developers forget to add it to one method)."
>
> I see the following options for the SFSBs to be used as websocket
> endpoints and not break the websocket API rules:
> a) augment the EJB spec to say that an SFSB cannot be destroyed if it is a
> websocket endpoint until then end of the websocket conversation
> b) add a @Stateful attribute
> c) add a method-level annotation @RetainIfSystemException
> d) add an annotation @RetainIfSystemException that can be applied at
> either the bean level or method level.
>
> Let me know your preference (and please do so asap as we are in the final
> stretch.
>
> thanks,
> -marina
>
>
> On 12/21/12 12:42 AM, Carlo de Wolf wrote:
>
>> 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 <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 '**
>>>>>>> retainIfBusinessMethodExceptio**n' to avoid confusion?
>>>>>>>
>>>>>>> thanks,
>>>>>>> -marina
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>
--
Jean-Louis