Announcement Announcement Module
No announcement yet.
PersistenceTranslationExceptionPostProcessor question Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • PersistenceTranslationExceptionPostProcessor question

    I'm a complete Spring noob working on my first Spring project. It's a huge project with many developers. The project is using JPA/Hibernate. The DAO objects for the original project were written with JPA templates. Some of our "legacy" developers are still clinging to using the templates for some reason. Since I'm just learning Spring I want to do away with the templates and just use the @PersistenceContext annotation and simple JPA calls on the EntityManager which seems to be the preferred way to do things now.

    I have all that working. My last step was to add the PersistenceTranslationExceptionPostProcessor so that all the JPA exceptions would be tranlated to Spring exceptions.

    When I add the PersistenceTranslationExceptionPostProcessor bean to my ApplicationContext.xml, all the old existing services which autowire old existing DAO objects fail because there is no matching bean to inject. After doing some research it seems because the old DAO objects extend the Spring JpaDaoSupport class that Spring is "proxying" (whatever that means) them and they no longer match the type of bean that is required by the service.

    We don't have the time/budget for me to go back and change all the existing DAO's at this point. But I would like to at least write all new classes without the templates. So is the bottom line that I am just out of luck?

    Here's another post I found related to the issue that probably does a better job of explaining the problem.


    Thanks so much for any advice.

  • #2
    I suggest a read up on AOP and the fact that spring uses proxies to enable AOP. By default Spring uses JDK Dynamic proxies (interface based proxies) and classes which extend JpaDaoSupport implement an interface (a couple I think). So it creates a proxy which acts like those interfaces.

    If you follow best practices your dao's also implement an interface to expose its public methods and you should be programming to those interfaces. If you don't use interfaces force class based proxies by specifing on an element that drives AOP (tx, config etc) somewhere define class-proxies and set it to true.