Bug 724800 (BRMS-640) - JPA Connector uses JPA 2 API
Summary: JPA Connector uses JPA 2 API
Alias: BRMS-640
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: Build Process, Modeshape
Version: BRMS 5.2.0.GA
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Ryan Zhang
QA Contact:
URL: http://jira.jboss.org/jira/browse/BRM...
Depends On:
TreeView+ depends on / blocked
Reported: 2011-07-15 06:33 UTC by Lukáš Petrovický
Modified: 2023-05-15 19:52 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-07-15 14:02:08 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 780720 0 urgent CLOSED JPA Connector uses JPA 2 API 2021-02-22 00:41:40 UTC
Red Hat Issue Tracker BRMS-640 0 Blocker Closed JPA Connector uses JPA 2 API 2013-04-11 05:19:30 UTC
Red Hat Issue Tracker MODE-1214 0 Blocker Resolved modeshape-connector-store-jpa issue when trying to start JBoss AS 5.1 2013-04-11 05:19:30 UTC
Red Hat Issue Tracker MODE-1251 0 Major Resolved Downgrade Hibernate to 3.3.2 in our '2.5.x' branch 2013-04-11 05:19:30 UTC

Internal Links: 780720

Description Lukáš Petrovický 2011-07-15 06:33:39 UTC
securitylevel_name: Public

JPA Connector uses JPA 2 API but currently supported containers only have JPA 1 packaged. En exmaple of the problem is
java.lang.NoSuchMethodError: javax.persistence.EntityManager.unwrap(Ljava/lang/Class;)Ljava/lang/Object;
	at org.modeshape.connector.store.jpa.JpaSource.determineDialect(JpaSource.java:1346)
	at org.modeshape.connector.store.jpa.JpaSource.getConnection(JpaSource.java:1295)
	at org.modeshape.connector.store.jpa.JdbcConnectionTest.shouldAutoDetectDialectAndSetOnJpaSource(JdbcConnectionTest.java:131)

ModeShape must be Java EE 5 compatible.

Comment 1 Lukáš Petrovický 2011-07-15 06:33:40 UTC
Link: Added: This issue Cloned from SOA-3174

Comment 2 Van Halbert 2011-07-15 14:02:08 UTC
This was fixed in MODE-1214, which will be in the next build.

Comment 3 Len DiMaggio 2011-07-20 14:33:37 UTC
Setting the fixed in value to 5.2 ER1 - as this is the 'next build.'

Comment 4 Petr Široký 2011-08-26 12:35:04 UTC
I am seeing very similar exception with ER3 build (and also with ER2). I am not sure who closed this issue, I though it is still opened and unresolved.

java.lang.NoSuchMethodError: javax.persistence.EntityManager.unwrap(Ljava/lang/Class;)Ljava/lang/Object;
	at org.modeshape.connector.store.jpa.HibernateAdapter.determineDialect(HibernateAdapter.java:154)
	at org.modeshape.connector.store.jpa.JpaSource.getConnection(JpaSource.java:1246)
	at org.modeshape.connector.store.jpa.JdbcConnectionTest.shouldAutoDetectDialectAndSetOnJpaSource(JdbcConnectionTest.java:131)

The HibernateAdapter class should be last one using the 'unwrap' method.

Comment 5 Lukáš Petrovický 2011-08-26 12:44:58 UTC
Requesting this to be incorporated into 5.2.
Also requesting BLOCKER flag as this issue must be fixed before we go GA.

Comment 6 Van Halbert 2011-08-26 12:52:26 UTC
Need a couple of things:
-  Are you trying to do deployment other than stop server, replace config, restart server
-  have you tried specifying the dialect, instead of leaving it blank
-  I assume your using hudson, can you point me to the job thats failing

Comment 7 Lukáš Petrovický 2011-08-26 13:27:59 UTC
After further investigation, it seems that we are building Modeshape against Hibernate 3.5 which brings in the JPA2 dependencies.

We should be building Modeshape against Hibernate 3.3 (as all the other platforms ought to be doing) and remain JEE 5 compatible.

Re-assigning to Ryan as this looks primarily like a build issue.

Comment 8 Petr Široký 2011-08-26 13:48:31 UTC
The 'unwrap' method is still used in HibernateAdapter class, so building against Hibernate 3.3 will not probably solve this issue. It has to be fixed in ModeShape source.

For Van:
We are not starting the server, we are just running unit tests with jars from modeshape-services.jar directory on classpath.

The dialect is always set by 'jpaSource.dialect' system property. Should we set some other property for HibernateAdapter class?

Comment 10 Petr Široký 2011-08-26 14:01:14 UTC
But we should definitely be building with Hibernate 3.3, because in that case, build process would fail and we would know that there is some error that has to be fixed.

Comment 11 Van Halbert 2011-08-26 14:15:33 UTC
I'm not sure what to tell you.   We can do the following:

-  the code is pulled from git, built and unit tests succeed
-  the code is built and deployed to AS5 without this issue
-  the code is built and repackaged for BRMS and SOA with out this issue

Note, the jar's that are in the modeshape-services.jar directory is not what ends up in the product, many are pulled out.      To try to run product related tests against what's in the modeshape-services.jar after a modeshape maven build could be problematic.

Comment 12 Petr Široký 2011-08-26 14:54:11 UTC
Sorry, I was not clear enough. We are using the product jars that are copied to jboss-as-web/server/default/deploy/modeshape-servies.jar by build.xml. Then we execute unit tests against these jars (and other jars from server lib dir, e.g. hibernate).

Comment 13 Lukáš Petrovický 2011-08-26 15:26:15 UTC
Alright, I dug into the code for the Modeshape 2.2 (aka BRMS 5.1) and Modeshape 2.5 (aka BRMS 5.2).


https://github.com/ModeShape/modeshape/blob/2.5.x/extensions/modeshape-connector-store-jpa/src/main/java/org/modeshape/connector/store/jpa/HibernateAdapter.java, line 151 and onward:

    public String determineDialect( EntityManager entityManager ) {
        // We need the connection in order to determine the dialect ...
        SessionFactoryImplementor sessionFactory = (SessionFactoryImplementor)entityManager.unwrap(Session.class).getSessionFactory();
        return sessionFactory.getDialect().toString();

Please note the method unwrap() that will not exist if using Hibernate 3.3. 


Modeshape 2.2 (that is proven working on Hibernate 3.3) does this in a different way.

https://github.com/ModeShape/modeshape/blob/2.2.x/extensions/modeshape-connector-store-jpa/src/main/java/org/modeshape/connector/store/jpa/JpaSource.java, line 1289 and onward:

    protected String determineDialect( EntityManager entityManager ) {
        // We need the connection in order to determine the dialect ...
        HibernateEntityManager em = (HibernateEntityManager)entityManager;
        SessionFactoryImplementor sessionFactory = (SessionFactoryImplementor)em.getSession().getSessionFactory();
        return sessionFactory.getDialect().toString();


From the above it is clear to me that, when provided with Hibernate 3.3 libraries, there is a corner case where Modeshape 2.5 will not work. This corner case is when the user provided no Hibernate dialect.

However, other parts of Modeshape are compiled against Hibernate 3.3 already. (Such as modeshape-connector-jdbc-metadata.) This is a dependency mess that needs to be fixed anyway.

Comment 14 Randall Hauch 2011-08-26 17:38:27 UTC
We've changed our branch ('2.5.x') used in the SOA-P and BRMS builds to be dependent upon Hibernate 3.3.2.GA rather than 3.5.2-FINAL (which we're still using in 'master'), and changed the way we access the dialect to be the same as what was in ModeShape 2.2. We do have integration tests that verify that we do indeed pull the correct dialect, and these tests ran successfully against HSQLDB and PostgreSQL. So hopefully this is fixed.

BTW, this changed was tracked on the project side via MODE-1251, and the changes were committed to the '2.5.x' branch and the issue marked as resolved.

Comment 15 Van Halbert 2011-08-26 17:46:14 UTC
COMMIT ID:   d02b4c9fed2e9b21a87e
Branch 2.5.x

Comment 16 Anne-Louise Tangring 2011-09-14 18:33:54 UTC
This is a test environmnet issue.

Comment 17 Petr Široký 2011-09-20 10:39:41 UTC
Verified fixed in 5.2.0 ER4.

Note You need to log in before you can comment on or make changes to this bug.