One error that's been bugging me since I started out using Spring together with JPA in a Glassfish Application Server was an exception such as the following:
com.sun.enterprise.deployment.backend.IASDeploymentException: Could not resolve a persistence unit corresponding to the persistence-context-ref-name [de.icanmakeit.jpokerstats.jpa.dao.GameDao/_entityManager] in the scope of the module called [jpokerstats]. Please verify your application.
The core problem here is that the mentioned GameDao uses the @PersistenceContext annotation to obtain an EntityManager from the container (or in this case Spring) but there are multiple persistence units defined in the persistence.xml (for the live system, for testing, etc.) and the Glassfish is unable to decide to which of these persistence units the annotation should be mapped.
Since I wanted all of this to be managed by Spring, I didn't bother this error and worked around it by downgrading the web.xml from 2.5 to 2.4 which disabled the J5EE dependency injection mechanism in Glassfish and let Spring do its job. Simply specifying @PersistenceContext(unitName="myunit") wasn't an option, since the same classes use a different persistence unit during JUnit tests and on the live server and explicitly specifying a persistence unit name breaks the unit tests.
Since my "inner ITIL" requires a developing solution after finding a workaround, I searched around the net, read a couple of dozen forum posts and finally figured out a way to solve the problem (...which I could have done earlier if I only had read the complete J5EE specification... *yawn*).
When deploying a 2.5 web application to Glassfish, the server examines it for any dependency injection annotations such as @PersistenceContext. It generates a default name for any unnamed annotation by using the FQCN, appended with a slash and the name of the field/property that is the injection target. In the above example, this would result in the name de.icanmakeit.jpokerstats.jpa.dao.GameDao/_entityManager. The server then tries find a persistence unit reference for this name. If there is only one persistence unit defined, this one will be used, otherwise the deployment descriptors are checked for configuration hints.
So in order to solve this problem, we have to provided these configuration hints. Adding the following few lines to the web.xml solves the problem:
-
<persistence-context-ref>
-
<persistence-context-ref-name>de.icanmakeit.jpokerstats.jpa.dao.GameDao/_entityManager</persistence-context-ref-name>
-
<persistence-unit-name>pokerstats_live</persistence-unit-name>
-
</persistence-context-ref>
This approach has one major drawback: if your software contains more than one @PersistenceContext injection target, you have to define a persistence-context-ref for each occurrence. This situation can be avoided by naming each @PersistenceContext annotation and giving them all the same name (note: the correct attribute is name, not unitName):
-
@PersistenceContext(name="pokerstats")
-
private EntityManager _entityManager;
All injection target with the same annotation name can now share a single persistence-context-ref (you can also use this name to look up the persistence unit using JNDI):
-
<persistence-context-ref>
-
<persistence-context-ref-name>pokerstats</persistence-context-ref-name>
-
<persistence-unit-name>pokerstats_live</persistence-unit-name>
-
</persistence-context-ref>
Update: Below you'll find the relevant parts of the Spring configuration file for the example above. It defines two beans, the first one makes the datasource, that has been configured in the Glassfish Server, available for use in Spring. The second one defines the entity manager factory that Spring will use to support the JPA context.
-
<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
-
<property name="jndiName" value="jdbc/__pokerstats"/>
-
</bean>
-
-
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
-
<property name="dataSource" ref="dataSource"/>
-
<property name="persistenceUnitName" value="pokerstats_live"/>
-
<property name="loadTimeWeaver">
-
<bean class="org.springframework.instrument.classloading.glassfish.GlassFishLoadTimeWeaver"/>
-
</property>
-
<property name="persistenceProvider">
-
<bean class="oracle.toplink.essentials.PersistenceProvider"/>
-
</property>
-
</bean>










#1 von Alexandre Verri am 28. Februar 2009 - 15:22
Fantastic! This is the solution that I`ve been looking for a long time.
I`ve tested and it works fine. Your explanations help me to understand better the “persistence-context-ref” feature.
Congratulations for share your experience with community. Best regards.
#2 von Alexandre Verri am 28. Februar 2009 - 22:44
Could you please post your Spring configuration file too?
Regards,
A.Verri
#3 von Hendrik Busch am 2. März 2009 - 10:03
@Alexandre: I’ve updated the post and included the relevant parts from the Spring configuration file.
#4 von Ram Aryal am 18. Oktober 2011 - 03:49
Perhaps I am going really slow today. But in the above example, don’t you still have to instantiate two different datasources (of two different kinds: jndi and driver-manager based) and inject them into LocalContainerEntityManagerFactoryBean ? How did you achieve this use-case when you are expanding your ‘live’ applicationContext into testApplicationContext?
Am I missing the link here?