Using Hibernate 3.2cr2, entity manager 3.2cr1, and annotations 3.2cr1

The problem (which is, I emphasize, probably not in any Hibernate code, but I'm looking for help tracking it down):

if I instantiate an EntityManagerFactory manually, via Persistence.createEntityManagerFactory("myPersistenceContext"), the EMF is created and I have useful EntityManagers I can use to work directly with JPA. I'm providing the connection details in the persistence.xml, like so:



(note that create-drop is set, so on startup, it will run SchemaExport; that's desirable because I'm trying to run some tests) If I instantiate an EntityManagerFactory with Spring 2.0M4 and its JPA support (org.springframework.orm.jpa.LocalEntityManagerFactoryBean), using the same persistence.xml that works above*, I get UnsupportedOperationExceptions when Spring uses JpaTemplate because in this environment, the UserSuppliedConnectionProvider appears to be in use:

This happens whether I inject an EntityManagerFactory or a JpaTemplate into the JpaDaoSupport-extending class. I'm pretty sure it's not a classloading issue, either, because I've tried adding the "manual" Persistence.createEntityManagerFactory calls to the classes under test, and they sail through without issue.

* verified this far: if I make persistence.xml not well-formed, my unit tests throws the expected SAX exceptions at startup.

I'm pretty sure it's something in the Spring environment that accounts for the difference; for one, Spring's LocalEntityManagerFactoryBean makes the same unexceptionable calls to Persistence.createEntityManagerFactory my code makes. Specifically, I'm looking for guidance about what could cause Hibernate to use the UserSuppliedConnectionProvider when the connection details are (apparently) available to it?

Of course, if anybody has run into the same problem and has a specific fix for this, I wouldn't turn my nose up at that either =)

So don't use the Spring bullshit. Why would you wrap a standardized API with a proprietary one?

database.* is not readable by hibernate
use hibernate.* (see the ref manual)

if database.* is something Spring specific, then it seems to be broken. They do not properly convert into Hibernate proeprties

I'm surprised, it took some Spring fanboy two days to put this on his blog, not a great reaction time. And he didn't get too creative on the personal insults, just very standard.

But we surely will see more of the greatness of JpaTemplate and JpaSpringCommittedTransactionNotsureTestSupportDAOSuperStuff in the future, so I might actually post a second time in 2006 here. You know, to "hound you" (sic), which is apparently what you do if you tell people that a particular software is, well, bullshit.

Don't use JpaTemplate. Don't use HibernateTemplate.

adamc,

ask the question in Spring forum instead, they are polite, helpful and take care of their users. They are also competent enough to help you which doesn't seem to be the case here. Also, why do we use other crap upon hibernate, well, maybe we also need an application layer and not only persistence which -"...basically is just a HashMap".

You don't need an exception wrapping template around JPA or Hibernate APIs. Period.

Oh now I understand all the excitement about my comments. You guys think that I said "Spring is bullshit". No, naturally it's the best thing since sliced bread.

Just like the original poster, I am talking about the wrapper templates and the newest incarnation of this lock-in API, JpaTemplate. Even the Javadoc says that it is very optional, as it only wraps standardized runtime exceptions in proprietary ones.

A more honest advice would be "useless" instead of "optional". If I missed something and anybody has a real reason why Spring users should wrap a standardized and perfectly usable API, I recommend adding it to the Javadoc.

"Gar," I say. That was the problem all along. The names of those properties were put in the pasted persistence.xml by a filtering operation, so I must have inadvertently switched the source of the properties between running the "bare" JPA code and the Springy stuff. I think I noticed it about the same time you posted (funny how staring at a problem for so long can blind you to the obvious). Thanks!

So, to answer my original question as posed (I swear, it wasn't about Spring!), UserSuppliedConnectionProvider is used in precisely the situations one would think it would be used, i.e. when the configuration as specified doesn't specify a connection for Hibernate.

Well, as to why I want to use Spring's JpaTemplate -- which, whatever you might think about the way it was posed, is a valid question -- it's not about exceptions, it's about transactions. The DAOs should be useable both within and outside containers that provide JTA, and from my current understanding this requires two different coding styles if you're using bare JPA. JpaTemplate allows me to not worry about the difference, and introducing the Spring dependence doesn't seem like a huge deal.

Transaction demarcation is not the job of the persistence layer, or the DAOs. Your DAOs require an instance of EntityManager (constructor, setter, lookup). How this EntityManager gets there and how any transaction boundaries are managed are orthogonal concerns.

I'd assume that Spring can handle both without forcing you to bind all your code to its APIs.