currently we're still runing JBoss 4.2.2 on production but would like to upgrade to a much more recent version. For our projects we're actually using JBoss as a better servlet container, the projects contain their dependencies and implementations of EE features. They do run on plain tomcat on the developers' machines.

Unfortunately I'm having trouble getting our most recent project to work on JBoss 7.0.2. It is based on JSF (MyFaces, Richfaces), JPA (Hibernate 3 in "JPA mode") and Spring 3. Also a generic DAO implementation (http://code.google.com/p/hibernate-generic-dao/) is involved. All dependencies and implementations are included in the *.war file, the same package runs fine on Tomcat 6 and JBoss 4.2.2.

After some fiddling with the configuration to prevent JBoss from injecting Hibernate 4 - which seems to be incompatible with our Spring version - I've got it to deploy. The landing page, containing JSF/Richfaces but no database content, renders fine. When I try to login or otherwise to access the database I get an Exception.

From what I can see in the code of the genericdao implementation this means that SessionFactory.getClassMetadata must have returned null for the entity classes. I am sure that Hibernate finds and knows my @Entity classes since there are a lot of log entries during the deployment that tell me there was an error creating the table because it already exists.

What I don't get is why the same code and almost the same configuration (I had to disable second level caching EhCache) works on JBoss AS 4.2.2 and on Tomcat 6 but not on JBoss AS 7.0.2 I have tried a nightly build, without success. This is the reason why I'm asking in the AS forum and not in the hibernate forum.

Two changes made here are hibernate.cache.use_second_level_cache and adding jboss.as.jpa.providerModule. The file is included in the same jar as the entity classes.

I know I'm supposed to let the app server handle database configuration for me and receive the connection from it. If this is absolutely necessary it would be an option, but I'd prefer to skip this step. At least for now.

I added a jboss-deployment-structure.xml to exclude "org.hibernate" to prevent injecting version 4; I need 3.x for now.

What am I doing wrong? How do I get this to work? Help would be very appreciated.

Btw: is there a way to exclude implicit dependencies? Can I tell AS7 that I want it to handle a given *.war as a servlet container would, no matter what it autodetects in there?

After that there are only some MyFaces INFO lines I already know and the exception on trying to access the DB.

There are two points I don't understand. This might be normal or be the missing hint.

First, the 56 repeats of the same block. But this matches the number of entity classes and they are not explicitly associated with a persistence unit. I guess that is what the log is trying to tell me.

Second the apparently two initializations of C3P0. This might mean that the whole entity manager is initiated and most likely instantiated twice. This could explain why I see the entities recognised (tried table creation) but unknown when asking the SessionFactory. What could lead to this and how do I prevent this?

The (56 times) repeated block (quoted below) corresponds to 56 @PersistenceContext or @PersistenceUnit injections into EntityManager or EntityManagerFactory variables (by the JPA container managed support in AS7). The found (rhylia) persistence unit definition is also shown each time. If your not using the EE container managed JPA support, you probably should disable it (since your not using it).

Try removing the EE container managed JPA support by deleting the following lines in as7/standalone/configuration/standalone.xml. I don't think this is causing the problem you are experiencing but it will reduce the noise at least.

Ah, I see. Yes, there are 56 occurences of @PersistenceContext public void setEntityManager(..) in the DAOs.

Sometimes it just helps to ask the right question.

After my last reply I tried to find out why there were apparently two entity manager instances created. Apparently AS 7 provides one for me after seeing the persistence.xml. On the other hand one was explicitly instantiated via spring because that's what is needed in non-EE environments.

I added an persistence-unit-ref to web.xml and reconfigured spring to use jee:jndi-lookup instead of a LocalContainerEntityManagerFactoryBean. Now accessing the database seems to work.

Unfortunately somehow my database has been corrupted so my application still does not work as expected. But the exception now thrown indicates that some data can actually be read from the database, via JPA/Hibernate. Anyway that's another problem and hopefully not connected to this topic.

Try removing the EE container managed JPA support by deleting the following lines in as7/standalone/configuration/standalone.xml. I don't think this is causing the problem you are experiencing but it will reduce the noise at least.

I haven't tried this yet. I think this would deactivate JPA support for the whole AS not just for one deployment. Which would be fine for now, but future projects should really aim for full EE compatibility - needing JPA support then. And as far as I can understand it my current (semi)working configuration uses the server's EE logic and behaviour and only overrides the implementation.

Try removing the EE container managed JPA support by deleting the following lines in as7/standalone/configuration/standalone.xml. I don't think this is causing the problem you are experiencing but it will reduce the noise at least.

I haven't tried this yet. I think this would deactivate JPA support for the whole AS not just for one deployment. Which would be fine for now, but future projects should really aim for full EE compatibility - needing JPA support then. And as far as I can understand it my current (semi)working configuration uses the server's EE logic and behaviour and only overrides the implementation.

Thank you for your answers and your time.

Yes, disabling JPA support for the whole AS, would be too disruptive but not as a learning exercise (to see what the impact is). It sounds like you don't need to follow this path anyway.