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
> <mailto: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