JPA and Spring

Mike and Merrick-

In my place of work there's a lot of momentum towards using Spring. Some projects are already using it and others are scheduling training and such. Most of the Spring documentation that I've run across talks about Spring and Hibernate, but not Spring and JPA. I know that with EJB3, the move to use JPA means that you can use Hibernate, Toplink and a number of implementations because you're interacting with them at the level of the standard - the API.

Can I use JPA with Spring and have persistence code that is JPA specific and not Spring or EJB3 specific?

Thanks,
Josh

Yes you can. I've been doing so for several years now, both in online webapps and stand-alone utility programs.

Although I'm not sure what you mean by "not Spring specific". If you mean not using the wrapper architecture that the older ORM technologies used with Spring, yes, that's true. In fact, use of the old wrapper stuff is specifically discouraged for Spring JPA. However Spring can still transparently wrap transaction management and similar amenities around methods in a Spring DAO/DataService class.

In fact, in that respect, it's sort of "inverse coding", since you no longer write the transaction logic in the Spring data access classes.

Hi Josh,

The Spring support for JPA is definitely there, and has been for a long time. I worked with Rod and Costin way back in the JPA 1.0 days to ensure a good integration, and since the philosophy of Spring is to decouple users from being tied to proprietary APIs, they are very big fans of JPA. In fact, their new rapid development framework, Spring Roo, generates JPA code and is extremely JPA-centric. They ship EclipseLink as the JPA 2.0 implementation.

I agree completely with your Mike, as always, except for this last part

Mike Keith wrote:Hi Josh,
They ship EclipseLink as the JPA 2.0 implementation.

I wouldn't completely say that, with Roo you can choose your JPA implementation, and one is not shipped over the other. As a matter of fact, they don't ship a JPA implementation with the Roo download. Just the Spring and Roo jars come with the Roo download.

To start up persistence in Roo it is simply

persistence setup --implementation {Here you put which you want, not what is given to you}

Something like that, the syntax might not be perfect, but at the shell line you setup persistence you define with JPA implementation you use.

Mark

Actually, I believe that Roo can generate Maven projects. And I once ran into a JPA issue that was so thorny that the only quick cure was to switch implementations. With Maven, I changed 2 dependencies, did some minor edits on persistence.xml and was running on the new implementation in under half an hour.

Hi,

My last sentence was out of place. It should have been said earlier in the paragraph since what I was referring to Spring, not Roo, since Spring ships with EclipseLink. It is their means of providing JPA 2 because no other provider is JPA 2 compliant right now. It seems I need an editor more than I thought...

Yes, the Roo syntax is when you set up the persistence part:

persistence setup --provider <provider>

My main point was that Roo is all about JPA and shows the JPA direction of Spring. To my knowledge it (Roo) doesn't even support specific proprietary persistence product APIs.

Tim Holloway wrote:Actually, I believe that Roo can generate Maven projects. And I once ran into a JPA issue that was so thorny that the only quick cure was to switch implementations. With Maven, I changed 2 dependencies, did some minor edits on persistence.xml and was running on the new implementation in under half an hour.

As a JPA spec guy I love to hear these kinds of stories. People don't always believe me when I tell them that we designed it to work like that, yet this kind of thing happens regularly.

Wow! I didn't expect that many responses, but that's exactly what I wanted to here. I think I've been looking at some older Spring documentation that was written before the JPA was a reality. It calls out Hibernate everywhere. I'm not opposed to Hibernate, I just want to write to the standard so that I can use another technology down the road if need be.

As for my comment about "non-Spring specific", I simply mean that my JPA code is JPA, not some JPA/Spring sort of thing. That way, if I end up doing JPA with EJB3, then the JPA part of it stays the same.

I know I'm talking in generalities, but given people's responses I think my question is answered. Spring supports JPA and only as much code as needs to be Spring-specific, is Spring-specific - as it should be.

Thank you for your time.
Josh

Mike Keith wrote:Hi,

My last sentence was out of place. It should have been said earlier in the paragraph since what I was referring to Spring, not Roo, since Spring ships with EclipseLink. It is their means of providing JPA 2 because no other provider is JPA 2 compliant right now. It seems I need an editor more than I thought...

Yes, the Roo syntax is when you set up the persistence part:

persistence setup --provider <provider>

My main point was that Roo is all about JPA and shows the JPA direction of Spring. To my knowledge it (Roo) doesn't even support specific proprietary persistence product APIs.

I can forgive you.

And use Roo is all about JPA and much much more.

Roo does not support any of the proprietary apis, you would have to write it yourself if you needed it. And you can edit any of the Entity Java classes to add properties and JPA or proprietary Persistence APIs as well as JSR-303 Validation Annotations.

Mark