Filed a JIRA for it as requested.
http://java.net/jira/browse/EJB_SPEC-88
I suspect we won't get to it next time around either as the @Transactional semantics address this issue -- the above was discussed in JavaEE 7 there as well. Not that @Transactional will be usable on EJBs, but I suspect the demand for fixing it for EJBs-only will be less.
-David
On Jan 30, 2013, at 6:49 PM, Marina Vatkina <marina.vatkina_at_oracle.com> wrote:
> David, Jean-Louis,
>
> I agree that exending @ApplicationException to allow finer grain control of the exception handling is a very clean solution (even though you can't turn PersistenceException into a non-roll-backing one because the JPA is required to mark transaction for rollback in most circumstances, or you can't undo a setRollbackOnly done by another bean as David's blog might suggest).
>
> Unfortunately it's too late to add it now as we are very tight with the resources, and I don't have an overwhelming support from the EG to try to push it through (sorry if anybody suggested it at the earlier stages of this project and I had missed that).
>
> Please file a JIRA (and I'll close http://java.net/jira/browse/EJB_SPEC-77 as rejected).
>
> thanks,
> -marina
>
>
> On 1/30/13 10:51 AM, David Blevins wrote:
>> Proposed this basic idea here: http://blog.dblevins.com/2010/07/applicationexception-is-evil-sort-of.html
>>
>>
>> This is essentially the approach being taken in the new @Transactional annotation. Doing it in a similar way with @ApplicationException would allow for some consistency. I love the simplicity of 'retainIf', but it definitely does raise questions on how it relates to ApplicationException.
>>
>> I'd support finer control via @ApplicationException to achieve the desired "retain" functionality.
>>
>> -David
>>
>> On Jan 15, 2013, at 9:36 AM, Marina Vatkina
>> <marina.vatkina_at_oracle.com>
>> wrote:
>>
>>
>>> This can also work (and is more flexible, and can be used in all bean types).
>>>
>>> Experts, I need your input on this ASAP.
>>>
>>> -marina
>>>
>>> On 1/14/13 9:36 AM, Jean-Louis MONTEIRO wrote:
>>>
>>>> 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
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Jean-Louis
>>>>
>