I've found that when I use the #ResponseStatus annotation on an unchecked error declaration, as discussed in this Baeldung article, it invalidates the #Transactional rollback behavior I'm relying on in my service layer.
How can I translate unchecked errors into HTTP responses without interfering with #Transactional?
Related
I am using Spring Boot 1.5.2.RELEASE and my service classes is annotated with
#Service
#Transactional(rollbackFor = Exception.class)
My unit test class is annotated with:
#RunWith(SpringRunner.class)
#SpringBootTest
I wish to roll back changes made in the database by unit test methods after test is finished.
One of the proposed solutions is to add #Transactional annotation over the test class, I tried it but this solution produces some issues, is that sometimes the test transaction is rolled back (even without no exceptions thrown!) before the service transaction is completed.
Is there another good solution to rollback test?
The solution with the #Transactional on the test class is the standard way of doing this. There is no way Spring Tx would roll back a transaction out of the blue, so I'd recommend looking closer into the issues that you encountered instead of inventing other solutions.
all changes will be rollbacked if didn't change default behaviour. And you don't have classes / methods with transaction propagation level = REQUIRES_NEW as it start independent transaction and can commit or rollback independently with the outer transaction
Transaction rollback and commit behavior
By default, test transactions will be automatically rolled back after
completion of the test; however, transactional commit and rollback
behavior can be configured declaratively via the #Commit and #Rollback
annotations.
#Rollback
#Rollback indicates whether the transaction for a transactional test
method should be rolled back after the test method has completed. If
true, the transaction is rolled back; otherwise, the transaction is
committed (see also #Commit). Rollback semantics for integration tests
in the Spring TestContext Framework default to true even if #Rollback
is not explicitly declared.
When declared as a class-level annotation, #Rollback defines the
default rollback semantics for all test methods within the test class
hierarchy. When declared as a method-level annotation, #Rollback
defines rollback semantics for the specific test method, potentially
overriding class-level #Rollback or #Commit semantics.
From the docs:
By default, test transactions will be automatically rolled back after
completion of the test; however, transactional commit and rollback behavior can be configured declaratively via the #Commit and #Rollback annotations.
Your comment:
sometimes the test transaction is rolled back (even without no
exceptions thrown !) before the service transaction is completed !
doesn't make sense to me. How did you know whether the txn completed or not if it was rolled back? Exceptions don't matter for tests, as I quoted the doc above.
Title speaks for itself.
Is PersistenceExceptionTranslationPostProcessor used solely for JPA implementations or is it relevant to use it with Spring's JdbcTemplate too?
And if there are two datasources needed each with their own JPA entity manager and transaction manager, do I still only need to specify one PersistenceExceptionTranslationPostProcessor for the entire application?
The auto-award bounty answer is wrong
~~~The correct answer is as follows~~~
I believe I've discovered the answer here:
http://www.deroneriksson.com/tutorials/java/spring/introduction-to-the-spring-framework/component-scanning-and-repository
The #Repository annotation can have a special role when it comes to converting exceptions to Spring-based unchecked exceptions. Recall that the JdbcTemplate handled this task for us. When we work with Hibernate, we’re not going to work with a Spring template that handles this conversion of Hibernate-based exceptions to Spring-based exceptions. As a result, in order to handle this conversion automatically, Hibernate DAOs annotated with #Repository will have their Hibernate exceptions rethrown as Spring exceptions using a PersistenceExceptionTranslationPostProcessor.
Further reading: http://www.deroneriksson.com/tutorials/java/spring/introduction-to-the-spring-framework/hibernate-daos
The paragraph above explicitly says:
Recall that the JdbcTemplate handled this task for us
So, to answer my own question, there is no need to use PersistenceExceptionTranslationPostProcessor with jdbcTemplate
Yes you can, The Spring exception translation mechanism can be applied transparently to all beans annotated with #Repository – by defining an exception translation bean post processor bean in the Context:
<bean id="persistenceExceptionTranslationPostProcessor"
class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor" />
As per it doc
Bean post-processor that automatically applies persistence exception translation to any bean marked with Spring's #Repository
annotation, adding a corresponding
PersistenceExceptionTranslationAdvisor to the exposed proxy (either an
existing AOP proxy or a newly generated proxy that implements all of
the target's interfaces).
Translates native resource exceptions to Spring's DataAccessException hierarchy. Autodetects beans that implement the
PersistenceExceptionTranslator interface, which are subsequently asked
to translate candidate exceptions.
All of Spring's applicable resource factories (e.g. LocalContainerEntityManagerFactoryBean) implement the
PersistenceExceptionTranslator interface out of the box. As a
consequence, all that is usually needed to enable automatic exception
translation is marking all affected beans (such as Repositories or
DAOs) with the #Repository annotation, along with defining this
post-processor as a bean in the application context.
So you can use it with Jdbctemplate as well as with any Jpa vendor implementation
As per is doc All of Spring's applicable resource factories (e.g. LocalContainerEntityManagerFactoryBean) implement the PersistenceExceptionTranslator interface out of the box, I think you still need to use PersistenceExceptionTranslationPostProcessor, because it used to translate all errors generated during the persistence process (HibernateExceptions, PersistenceExceptions...) into DataAccessException objects.
I'm using spring-data-jpa to read/write to my DB. I've read through the documentation for spring-data and the one thing that I can't seem to locate is how it handles exceptions.
I am looking to catch any type of exception thrown by a repo action. Is there a way of doing this short of just wrapping the individual repo action in a try/catch and catching any RuntimeException? I'd rather avoid that as that is an even larger catch-all than I'd like.
Does spring-data wrap all exceptions in its own SpringDataException() or something similar? I've looked through the spring-data-commons jar as well as the spring-data-jpa jar and didn't find anything applicable.
Does spring-data wrap all exceptions in its own SpringDataException() or something similar
Yes, sort of. spring-data(-jpa) enable exception translation from JPA exceptions to Spring’s DataAccessException hierarchy:
From spring-data-jpa reference implementation:
...Beyond that, it activates persistence exception translation for all beans annotated with #Repository to let exceptions being thrown by the JPA persistence providers be converted into Spring’s DataAccessException hierarchy.
From Spring reference implementation:
Spring provides a convenient translation from technology-specific exceptions like SQLException to its own exception class hierarchy with the DataAccessException as the root exception. These exceptions wrap the original exception so there is never any risk that one might lose any information as to what might have gone wrong...
For more read about Spring DAO support
Spring AOP and AspectJ are usually used for Exception handling and Logging. Is there any other feature for which we are using aspectJ and spring AOP.
Yes, transactional behavior is the first to come to mind. Take a look at the #Transactional annotation. You mark a method with the annotation and the container will take the necessary steps to start a transaction before your method executes and commit or roll back the transaction when it ends.
Security is another nice application of AOP. You can annotate a method to mark it as requiring certain permissions. For example, in a web application, you might have a few handler methods for requests that require the user to be an administrator. Instead of implementing that logic in each handler method, you extract it to some AOP advice and put a joinpoint at each of those methods.
Aspects can be used as any type of filter really. You can allow, prevent, modify access to a method.
Note that Spring's support for AOP is limited to method invocation join points.
Upon starting my application, I get numerous warnings along the lines of o.s.aop.framework.Cglib2AopProxy 'Unable to proxy method [public final void org.springframework.jdbc.core.support.JdbcDaoSupport.setDataSource(javax.sql.DataSource)] because it is final: All calls to this method via a proxy will be routed directly to the proxy.' for about a dozen or so functions.
Now I perfectly understand that proxy-based aspects cannot be applied to final methods. However, I did not (on purpose, at least) try to weave any aspects into JdbcDaoSupport. I suspect it comes from <tx:annotation-driven />. Is there anything I can do to silence these warnings or, better yet, exclude those classes from the aspect weaving?
This is most likely caused by the #Transactional annotation, Spring wraps your DAO in a proxy to add the transactional behavior.
I would recommend to make your DAO implement an Interface (create and use an interface for your DAO), this will allow Spring to use a JDK dynamic proxy instead of having to use CGLib.
Using CGLIB has a limitation that methods marked as final in target class can’t be advised as final methods can’t be overridden (CGLIB creates a subclass of target class at runtime) but this limitation disappears in case of using JDK dynamic proxies.
Reference
Maybe you have extended JdbcDaoSupport and added #Transactional annotations.
You can set the Cglib2AopProxy logger to log level ERROR to avoid the warn messages. For example if using log4j and log4j.properties:
log.logger.org.springframework.aop.framework.Cglib2AopProxy = ERROR
You should use interfaces for dependency injection, the most reasons for this are described here and here.
You can read documentation about proxying mechanic for details why you see this warning.
And please vote for feature request of inspection for IntelliJ that may helps us to avoid this warnings. BTW It also contains a good explanation.
Spring Boot now uses CGLIB proxying by default, including for the AOP support. If you need interface-based proxy, you’ll need to set the spring.aop.proxy-target-class to false.
spring.aop.proxy-target-class=false