hi greg,

yes - ordering via beans.xml entries is available since cdi 1.0.
however, ds offers special (optional) support for cdi 1.1+.
in this case it's about @Priority (which gets added automatically to
interceptors provided by ds to enable them across bean deployment archives).
since some versions of weld have a "special" behavior once you mix
@Priority and beans.xml entries, i just mentioned the approach with
@Priority.

regards,
gerhard

http://www.irian.at

Your JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache
MyFaces, DeltaSpike and OpenWebBeans



2015-09-20 22:35 GMT+02:00 Grzesiek <[email protected]>:

> Hi Thomas,
>
> Thank you @Gerhard for yesterday tips, although I've failed to make
> *@javax.annotation.Priority* work for me (don't know why, silently
> ignored?).
> I have read this CDI article
> <
> http://www.mastertheboss.com/jboss-frameworks/cdi/interceptors-and-decorators-tutorial
> >
> and found out that order of interceptors can be defined inside *beans.xml.
> *And
> it solved my problem!
>
> @Thomas - truly very good answer. Although I've managed to find an answer
> already, you guessed it perfectly. I'm impressed.
>
> Some insights:
>
> AFAIK there is no interceptor of interceptors,
> >
>
> Very good point, I've tried it blindly in act of desperation. But I'm
> disappointed that Weld didn't complain to such incorrect code.
>
> should work in your case too, if the sequence (order in beans.xml?) of
> > interceptors allows the @Transactional interceptor to be invoked before.
> >
>
> It was the key. Hats off :-)
>
> There are several possible ways to define order of interceptors, one of
> > them is beans.xml
> >
>
> I'm curious about alternatives. Could you point me to any?
>
>
> BTW:
> I've also tried *@Inherited* for my own interceptor binding (to inherit
> from @Transactional), but it was extremely confusing, because I've found
> out, that inheritance hierarchy doesn't matter when it comes to the
> interceptors *execution order* (!). So what is the point of *@Inherited*?
> None. Making @Stereotype has exactly the same outcome and is far more
> clearer, am I right?
>
> Also I'm disappointed that Weld silently ignored `@Inherited` annotation,
> in case when pointed interceptor hasn't been previously declared inside
> `beans.xml`.
>
> Regards,
> Greg
>
>
>
>
> 2015-09-20 19:40 GMT+02:00 Thomas Frühbeck <[email protected]>:
>
> > Hi Greg,
> >
> > AFAIK Interceptor and CDI Bean (which is not @ManagedBean) are orthogonal
> > concepts, I would not mix them into one - even if it occasionally worked
> >
> > @Transactional is an interceptor binding on its own, AFAIK there is no
> > interceptor of interceptors, so a interceptor binding annotation on an
> > interceptor - other than qualifying the interceptor itself - is
> meaningless.
> > So adding the interceptor binding annotation @Transactional to an
> > interceptor - if ever - would make it responsible to _handle_ the
> > interception - in this case: provide the transaction, right?
> >
> > Injection into an interceptor is ok, so it should work in your case too,
> > if the sequence (order in beans.xml?) of interceptors allows the
> > @Transactional interceptor to be invoked before.
> > There are several possible ways to define order of interceptors, one of
> > them is beans.xml
> >
> > You can easily see the order of interceptors in stack trace if setting a
> > breakpoint into the intercepted method.
> >
> > Thomas
> >
> > Am 19.09.2015 um 19:35 schrieb Grzesiek:
> >
> >> Hi Gerhard, thanks for answering. Nice to see that somebody cares.
> >>
> >> your code isn't valid with cdi.
> >> I'm surprised. Why? Could you give me a reason?
> >>
> >> I've tried both of your hints also. But still no luck.
> >>
> >> ... just create a cdi-stereotype annotation (e.g. @Service) and annotate
> >>
> >>> that one with both interceptor-annotations.
> >>>
> >>> // btw. to be honest, I've already created this stereotype annotation,
> >> exactly with name "@Service" ;-)
> >>
> >>
> >> I guess my whole problem is about the order of the interceptors. My
> custom
> >> *@DetectIntegrityConstraintViolation* is processed first, before
> >> *@Transactional* - thus exception during execution of the former
> >>
> >> interceptor. If yes how to solve this? Any other clues?
> >>
> >> Greg
> >>
> >>
> >> 2015-09-19 18:16 GMT+02:00 Gerhard Petracek <[email protected]>:
> >>
> >> hi greg,
> >>>
> >>> you are very welcome to ask questions on this list.
> >>> (helping deltaspike-users is the main intention here...)
> >>>
> >>> @your issue:
> >>> your code isn't valid with cdi. if you don't like to use both
> >>> interceptor-annotations in your service-classes, just create a
> >>> cdi-stereotype annotation (e.g. @Service) and annotate that one with
> both
> >>> interceptor-annotations.
> >>>
> >>> regards,
> >>> gerhard
> >>>
> >>>
> >>>
> >>> 2015-09-19 17:56 GMT+02:00 Grzesiek <[email protected]>:
> >>>
> >>> Hi all,
> >>>>
> >>>> It is my first post here, usually I would use StackOverflow, but there
> >>>> is
> >>>> almost none questions/ answers tagged with DeltaSpike.
> >>>>
> >>>> Sorry for wasting your precious time. But I'm struggling for a couple
> of
> >>>> hours with not working @Transactional interceptor from
> >>>> *deltaspike-jpa-module* inside my own interceptor.
> >>>>
> >>>> Details:
> >>>> My own interceptor: @DetectIntegrityConstraintViolationInterceptor
> needs
> >>>>
> >>> to
> >>>
> >>>> have injected an EntityManager instance, but unfortunately I'm always
> >>>> getting "*java.lang.IllegalStateException: Transaction not active*"
> >>>>
> >>> inside
> >>>
> >>>> this interceptor (injection of EntityManager works fine, but
> transaction
> >>>>
> >>> is
> >>>
> >>>> not started automatically).
> >>>>
> >>>> Do somebody know why?
> >>>>
> >>>> My use case is quite simple: one service, marked with @Transactional,
> >>>> and
> >>>> its one method is also annotated with
> >>>> @DetectIntegrityConstraintViolationInterceptor.
> >>>>
> >>>> I've been trying blindly a couple of combinations, but none works:
> >>>>    * I've marked also my interceptor with @Transactional
> >>>>    * I've marked also both my Interceptor and InterceptorBinding with
> >>>> @Transactional
> >>>>
> >>>> Simplified code:
> >>>>
> >>>> @ManagedBean // make it a CDI bean
> >>>>
> >>>>> @Interceptor
> >>>>> @DetectIntegrityConstraintViolation
> >>>>> public class DetectIntegrityConstraintViolationInterceptor {
> >>>>>
> >>>>>      @Inject
> >>>>>      private EntityManager em;
> >>>>>
> >>>>>      @AroundInvoke
> >>>>>
> >>>>>      // @Transactional     // ALSO BLINDLY TRIED THIS, but no luck
> >>>>      public Object processInvocation(InvocationContext ctx)
> >>>>
> >>>>>              throws Exception {
> >>>>>          Object o = null;
> >>>>>          try {
> >>>>>              o = ctx.proceed();
> >>>>>              em.flush();          // THIS CAUSES EXCEPTION, AS
> >>>>>
> >>>> TRANSACTION
> >>>
> >>>> DOESN'T EXIST
> >>>>>          } catch (PersistenceException ex) {
> >>>>>              // ....
> >>>>>          }
> >>>>>          return o;
> >>>>>      }
> >>>>>
> >>>>> }
> >>>> Service class looks like:
> >>>>
> >>>> import org.apache.deltaspike.jpa.api.transaction.Transactional;
> >>>> @Transactional
> >>>>
> >>>>> public class MyServiceBean implements MyService {
> >>>>>
> >>>>>      @Inject
> >>>>>      EntityManager em;
> >>>>>
> >>>>>      @DetectIntegrityConstraintViolation
> >>>>>      public ResponseEntity<User> createUser(User user) {
> >>>>>          em.persist(user);
> >>>>>      }
> >>>>> }
> >>>>>
> >>>>> Tip: EntityManager was tried both: @TransactionScoped and
> >>>> @RequestScoped
> >>>>
> >>> -
> >>>
> >>>> result similar, only message was a bit different ;-)
> >>>>
> >>>> Any clues?
> >>>> Ps. I'm sorry, if above code is not readable, bu I don't know how to
> >>>>
> >>> format
> >>>
> >>>> code inside an email.
> >>>>
> >>>> Libs versions used:
> >>>>   * deltaspike-jpa-module-api 1.4.1
> >>>>   * weld-servlet-core  2.2.0.Final
> >>>>   * JDK 1.7
> >>>>
> >>>> Kind regards
> >>>> Greg Demecki
> >>>>
> >>>>
> >
>

Reply via email to