Hi Greg,
I'm happy to hear that you found a solution.
Regarding interceptors / activation / ordering see:
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#enabled_interceptors
And always watch out for the subtle differences between CDI 1.0, 1.2,
2.0, Weld, OWB, etc. and the implementation of the framework at hand...
Guys like these here at DeltaSpike really are incredible geeks (kudos,
kudos, kudos)!
CDI has become a vast area of technology. Though quickstarts look so
easy I have become entangled in my own code too often already.
IMHO it is absolutely necessary to stay focused when applying CDI and
concentrate on the real need, but then it is incredible to work with :-)
Thomas
Am 20.09.2015 um 22:35 schrieb Grzesiek:
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
