Hibernate Books

All times are UTC - 5 hours [ DST ]



Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: What enables UserSuppliedConnectionProvider?
PostPosted: Thu Jun 01, 2006 10:38 am 
Newbie

Joined: Tue Mar 08, 2005 1:21 pm
Posts: 2
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:

Code:
<properties>
      <property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect"/>
      <property name="database.connection.url" value="jdbc:hsqldb:mem:kb"/>
      <property name="database.connection.driver_class" value="org.hsqldb.jdbcDriver"/>
      <property name="database.connection.password" value=""/>
      <property name="database.connection.username" value="sa"/>
      <property name="hibernate.hbm2ddl.auto" value="create-drop"/>
      <property name="hibernate.show_sql" value="true"/>
</properties>


(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:

Code:
java.lang.UnsupportedOperationException: The user must supply a JDBC connection
   at org.hibernate.connection.UserSuppliedConnectionProvider.getConnection(UserSuppliedConnectionProvider.java:30)
   at org.hibernate.tool.hbm2ddl.SuppliedConnectionProviderConnectionHelper.prepare(SuppliedConnectionProviderConnectionHelper.java:27)
   at org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:178)
   at org.hibernate.tool.hbm2ddl.SchemaExport.create(SchemaExport.java:131)
   at org.hibernate.impl.SessionFactoryImpl.&amp;init&amp;(SessionFactoryImpl.java:308)
   at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1213)
   at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:631)
   at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:760)
   at org.hibernate.ejb.Ejb3Configuration.createFactory(Ejb3Configuration.java:151)
   at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:205)
   at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:114)
   at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:37)
   at org.springframework.orm.jpa.LocalEntityManagerFactoryBean.createEntityManagerFactory(LocalEntityManagerFactoryBean.java:102)
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 =)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 01, 2006 2:28 pm 
Hibernate Team
Hibernate Team

Joined: Mon Aug 25, 2003 9:11 pm
Posts: 4592
Location: Switzerland
So don't use the Spring bullshit. Why would you wrap a standardized API with a proprietary one?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jun 02, 2006 7:56 pm 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7179
Location: Atlanta, USA
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

_________________
Emmanuel
Check Hibernate Search in Action out


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 03, 2006 3:46 am 
Hibernate Team
Hibernate Team

Joined: Mon Aug 25, 2003 9:11 pm
Posts: 4592
Location: Switzerland
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jun 05, 2006 3:31 am 
Newbie

Joined: Wed May 24, 2006 8:47 am
Posts: 2
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".


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jun 05, 2006 7:06 am 
Hibernate Team
Hibernate Team

Joined: Mon Aug 25, 2003 9:11 pm
Posts: 4592
Location: Switzerland
You don't need an exception wrapping template around JPA or Hibernate APIs. Period.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jun 05, 2006 7:42 am 
Hibernate Team
Hibernate Team

Joined: Mon Aug 25, 2003 9:11 pm
Posts: 4592
Location: Switzerland
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jun 05, 2006 10:57 am 
Newbie

Joined: Tue Mar 08, 2005 1:21 pm
Posts: 2
emmanuel wrote:
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


"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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jun 05, 2006 11:22 am 
Hibernate Team
Hibernate Team

Joined: Mon Aug 25, 2003 9:11 pm
Posts: 4592
Location: Switzerland
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.