I have attached a simple, one-Servlet project that duplicates this issue. You can also see the issue reported in this Stack Overflow question (I didn't post that) and this forum post (posted by the same person it appears).
The attached project worked fine with Hibernate 4.2.x and through Hibernate 4.3.0.Beta4. I have not tested with 4.3.0.Beta5-4.3.0.CR1, but 4.3.0.CR2 and 4.3.0.Final result in the following error on Tomcat 7 and 8:
It would appear that, starting somewhere in 4.3.0.Beta5, 4.3.0.CR1, or 4.3.0.CR2, Hibernate stopped being able to resolve JNDI DataSource resources in Tomcat. This makes Hibernate 4.3.0.Final completely unusable, meaning this is a blocking issue. Until this is fixed, I will have to downgrade to 4.3.0.Beta4.
The reporter of the Stack Overflow question and forum post believes he has found the likely culprit: a change in the JndiServiceImpl#locate method.
, I finally succeeded compiling and tested your fix. It works!
I tested with hibernate-core 4.3.5 and tomcat didn't find the datasource. Then I simply exchanged hibernate-core with the fixed one and tomcat found my datasource.
, thanks much for the confirmation
Closing resolved issued in preparation for releasing 4.3.6.
We will need to change how this was implemented. The fix as-is is causing problems in other environments (specifically see HHH-9446).
Would any of you Tomcat users be willing to help us understand Tomcat/Jetty class-loading to help us fix this in a more portable way? For anyone interested, let's continue the discussion on HHH-9446. Not to be dramatic, but no help from folks affected here might mean that the fix for HHH-9446 leads to new problems in your environment.
I have asked to have a look at this because he best understands class-loading.
Not sure, could we restore the saved (Tomcat) TCCL for the org.hibernate.engine.jndi.internal.JndiServiceImpl.locate() call perhaps?