Link: Added: This issue Cloned from SOA-3174

This was fixed in MODE-1214, which will be in the next build.

Setting the fixed in value to 5.2 ER1 - as this is the 'next build.'

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.

Requesting this to be incorporated into 5.2.
Also requesting BLOCKER flag as this issue must be fixed before we go GA.

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

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.

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?

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.

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.

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

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:

    @Override
    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.

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.

COMMIT ID:   d02b4c9fed2e9b21a87e
Branch 2.5.x

This is a test environmnet issue.

Verified fixed in 5.2.0 ER4.