3.2.13.2. Seam 2.2 Archive Migration Issues

Seam 2.2 Drools and Java 7 are incompatible and fail with an org.drools.RuntimeDroolsException: value '1.7' is not a valid language level error.

When the Spring example is run using the signed cglib.jar that shipped with Seam 2.2.5 in JBoss EAP 5, it fails with the following root cause:

java.lang.SecurityException: class "org.jboss.seam.example.spring.UserService$$EnhancerByCGLIB$$7d6c3d12"'s signer information does not match signer information of other classes in the same package

The work around for this issue is to unsign the cglib.jar as follows:

zip -d $SEAM_DIR/lib/cglib.jar META-INF/JBOSSCOD\*

The cause of this issue is the SOAP message header being null when processing the message in the SOAPRequestHandler and consequently, the conversation ID not being set.

The work around for this issue is to override org.jboss.seam.webservice.SOAPRequestHandler.handleOutbound, as described in https://issues.jboss.org/browse/JBPAPP-8376.

This bug is caused by changes in the JNDI name of UserTransaction in JBoss EAP 6.

The work around for this issue is to override org.jboss.seam.transaction.Transaction.getUserTransaction, as described in https://issues.jboss.org/browse/JBPAPP-8322.

This bug is caused by the incompatibility between seam-resteasy-2.2.5 included in JBoss EAP 5.1.2) and RESTEasy 2.3.1.GA included in JBoss EAP 6.

The work around for this issue is to use the jboss-deployment-structure.xml to exclude resteasy-jaxrs, resteasy-jettison-provider, and resteasy-jaxb-provider from the main deployment and resteasy-jaxrs, resteasy-jettison-provider, resteasy-jaxb-provider, and resteasy-yaml-provider from the jboss-seam-tasks.war as described in https://issues.jboss.org/browse/JBPAPP-8315. It is then necessary to include the RESTEasy libraries bundled with Seam 2.2 in the EAR.

An error page with "Caused by javax.servlet.ServletException with message: "javax.el.ELException: /main.xhtml @36,71 value="#{hotelSearch.pageSize}": org.jboss.seam.core.LockTimeoutException: could not acquire lock on @Synchronized component: hotelSearch" or similar error message is displayed.

The problem is that Seam 2 does its own locking outside the stateful session bean (SFSB) lock and with a different scope. This means that if a thread accesses an EJB twice in the same transaction, after the first invocation it will have the SFSB lock, but not the seam lock. A second thread can then acquire the seam lock, which will then hit the EJB lock and wait. When the first thread attempts its second invocation it will block on the seam 2 interceptor and deadlock. In Java EE 5, EJBs would throw an exception immediately on concurrent access. This behavior has changed in Java EE 6.

The work around for this issue is to add @AccessTimeout(0) to the EJB. This will cause it to throw a ConcurrentAccessException immediately when this situation occurs.

The dvdstore example displays the following error:

JBAS011437: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it. This can be avoided by changing application code, either eliminate the extended persistence context or the transactional context. See JPA spec 2.0 section 7.6.3.1.

This problem is due to changes in the JPA specification.

The fix for this issue is to change the persistence context to transactional in the CheckoutAction and ShowOrdersAction classes and use the entity manager merge operation in the cancelOrder and detailOrder methods.

JBoss Cache is not supported in JBoss EAP 6. This causes JBoss Cache Seam Cache provider to fail in a Seam application on the application server with a

java.lang.NoClassDefFoundError: org/jboss/util/xml/JBossEntityResolver

.

The fix for this issue is to list all the entity classes in the persistence.xml file manually. For example:

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
    <persistence-unit name="example_pu">
        <description>Hibernate 3 Persistence Unit.</description>
        <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
        <properties>
            <property name="jboss.as.jpa.providerModule" value="hibernate3-bundled" />
        </properties>
        <class>com.acme.Foo</class>
        <class>com.acme.Bar</class>
    </persistence-unit>
</persistence>

This issue is a result of changes in JBoss EAP 6 to implement the new modular class loading system and to adopt the new standardized JNDI namespace conventions. The java:app namespace is designated for names shared by all components in a single application. Non-EE threads, such as Quartz asynchronous threads, must use the java:global namespace, which is shared by all applications deployed in an application server instance.

If you receive a javax.naming.NameNotFoundException when you try to call EJB Seam components from Quartz asynchronous methods, you must modify the components.xml file to use the global JNDI name, for example:

<component class="org.jboss.seam.example.quartz.MyBean" jndi-name="java:global/seam-quartz/quartz-ejb/myBean"/>

For more information on JNDI changes, refer to the following topic: Section 3.1.8.1, “Update Application JNDI Namespace Names” . For more information on this specific issue, refer to BZ#948215 - Seam2.3 javax.naming.NameNotFoundException trying to call EJB Seam components from quartz asynchronous methods in the 2.2.0 Release Notes for Red Hat JBoss Web Framework Kit on the Red Hat Customer Portal.