Exactly!
The actual ApplicationException usage is causing a large set of
ApplicationExceptions with complicated graphs and inheritance which leads
to something always difficult to maintain, and a big mess.
Also noticed got the opportunity to read the interceptor blog post. To keep
in mind with Mark's feebacks.
Jean-Louis
2013/1/30 David Blevins <david.blevins_at_gmail.com>
> 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-24and 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
> >
>
>
--
Jean-Louis