Posts Tagged glassfish

JSF: Multiple ‘javax.faces.ViewState’ hidden fields

If you happen to have more than one h:form in your JavaServer Faces page, JSF will generate a hidden input field with javax.faces.ViewState as its name and id for each form. This breaks XHTML compatability because you have more than one element with the same id which isn’t allowed. I recently came across this myself and had some trouble finding a solution on Google. The problem results from an error in the JSF specification itself and thus cannot be solved easily but both major implementations have builtin workarounds:

For MyFaces, you can specify a context parameter in your web.xml called org.apache.myfaces.RENDER_VIEWSTATE_ID and set it to false. It will prevent MyFaces from rendering duplicate ids. For more information please refer to the MyFaces Bugtracking system (MYFACES-1700).

If you use the reference implementation (currently Mojarra), the name of the context parameter for the web.xml is com.sun.faces.enableViewStateIdRendering and you must also set it to false to prevent the RI from generating duplicate ids. For more information, please refer to the JSF-RI FAQ or the bugtracking system (issue 443).

, , , , , , ,

2 Kommentare

How to get rid of “Could not resolve a persistence unit corresponding to the persistence-context-ref-name …” exceptions

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:

XML:
  1. <persistence-context-ref>
  2.     <persistence-context-ref-name>de.icanmakeit.jpokerstats.jpa.dao.GameDao/_entityManager</persistence-context-ref-name>
  3.     <persistence-unit-name>pokerstats_live</persistence-unit-name>
  4. </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):

JAVA:
  1. @PersistenceContext(name="pokerstats")
  2. 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):

XML:
  1. <persistence-context-ref>
  2.     <persistence-context-ref-name>pokerstats</persistence-context-ref-name>
  3.     <persistence-unit-name>pokerstats_live</persistence-unit-name>
  4. </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.

XML:
  1. <bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
  2.     <property name="jndiName" value="jdbc/__pokerstats"/>
  3. </bean>
  4.  
  5. <bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
  6.     <property name="dataSource" ref="dataSource"/>
  7.     <property name="persistenceUnitName" value="pokerstats_live"/>
  8.     <property name="loadTimeWeaver">
  9.         <bean class="org.springframework.instrument.classloading.glassfish.GlassFishLoadTimeWeaver"/>
  10.     </property>
  11.     <property name="persistenceProvider">
  12.         <bean class="oracle.toplink.essentials.PersistenceProvider"/>
  13.     </property>
  14. </bean>

, , , , , , ,

3 Kommentare