[GLASSFISH-17660] When configuring Spring exception translator (org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor) in the application context file, Glassfish issues a java.lang.IllegalStateException Created: 08/Nov/11  Updated: 09/Nov/11

Status: Open
Project: glassfish
Component/s: None
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: galdunate Assignee: scatari
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish V3.1.1 (Windows), Spring 3.0.5, Eclipselink 2.3.0 (integrated into Glassfish), IBM DB2 V8.1.18.980 (Linux), JDBC Driver type 4


Attachments: Text File server.log    
Tags: exception-translation, glassfish-3-1-1, jpa, spring

 Description   

When configuring the Spring bean used to translate exceptions from JPA hierarchy to Spring DataAccessException (org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor) in the application context file running under Glassfish, when the application server starts the application, it issues a "java.lang.IllegalStateException: No persistence exception translators found in bean factory. Cannot perform exception translation."

However, if you read the JavaDoc file for this bean, it says literally "All of Spring's applicable resource factories 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 DAOs) with the Repository annotation, along with defining this post-processor as bean in the application context.", what is obviously not happening.

When you run this same configuration under Tomcat (with the appropriate application context changes, considering Tomcat is not a JEE server) it works fine.

I'm attaching the server.log file for Glassfish where you can find the whole big big stack trace for this situation. Please review the last lines of server.log. Hope you may come up with the solution. Thank you in advance.



 Comments   
Comment by shreedhar_ganapathy [ 09/Nov/11 ]

Transferring to Sathyan for appropriate assignment and consideration in 3.1.2

Generated at Mon May 04 15:31:43 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.