|RE: Mybatis-guice, configuring default exception type for @Transactional||christia...@ircm.qc.ca||7/19/12 7:48 AM|
In such a case, it may be better to add an your own rethrow interceptor over @Transactional.
That way, you don’t have to modify every @Transactional annotations and it’s easier to maintain.
I really appreciate the @Transactional annotation provided by mybatis-guice (and by the way, thanks Simone for maintaining it over years).
However, I would like my service layer to use my own data access exception class all the time so it would be great if I could define a default value for rethrowExceptionAs in a single place instead of specifying it above every method.
Looking at the source code, it does not seem possible at the moment but maybe it's worth considering in a future release?
|RE: Mybatis-guice, configuring default exception type for @Transactional||christia...@ircm.qc.ca||7/19/12 7:50 AM|
Sorry, I didn’t read your question correctly.
But my point is still valid. By using a custom interceptor you can handle the exception the way you like and MyBatis-Guice interceptor will still work its magic.
|Re: Mybatis-guice, configuring default exception type for @Transactional||Simone Tripodi||7/21/12 1:02 PM|
I think it could be possible - can you feel me an issue as a reminder, please?
|Re: Mybatis-guice, configuring default exception type for @Transactional||Stephane C.||7/25/12 12:22 AM|
Thanks for your answer, I will have a look and investigate your solution further.
I also thought there could be a way to achieve this kind of behavior using annotation and interceptors, but for some reasons I am a bit shy when it comes to AOP stuff.
|RE: Mybatis-guice, configuring default exception type for @Transactional||christia...@ircm.qc.ca||7/25/12 5:57 AM|
I agree. Interceptors seems non-trivial at first and you may encounter some problems because it usually creates proxies.
But once you taste it, it becomes addictive!
The main thing you must keep in mind with MyBatis-Guice @Transactional is that the annotation will only work on methods that can be overridden by a subclass. So only use @Transactional on public or protected methods.
Don’t use @Transactional on private methods. That doesn’t work. I haven’t tested on package methods.
This also applies to any interceptor you use with Guice or Spring.
As an additional hint, remember that if you annotate an interface method but not its actual implementation, you will need to check for the annotation recursively one the parents. I doubt Guice will check parent annotations for you.