[jbossseam-issues] [JBoss JIRA] Closed: (JBSEAM-1688) SMPC is broken on Glassfish

SMPC is broken on Glassfish --------------------------- Key: JBSEAM-1688 URL: http://jira.jboss.com/jira/browse/JBSEAM-1688 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 2.0.0.BETA1 Environment: Glassfish v2-b50g (beta3), Windows XP Reporter: Guy Veraghtert Assigned To: Gavin King Fix For: 2.0.0.CR1 Attachments: JBSEAM-1688.zip (this issue is related to http://jira.jboss.org/jira/browse/JBSEAM-456, regression!) Adding @In to an entityManager-field to a SFSB causes a java.lang.IllegalStateException: Operation not allowed on Glassfish. In org.jboss.seam.transaction.Transaction the UserTransaction is retrieved via Naming.getInitialContext().lookup("UserTransaction"); Glassfish doesn't throw a NameNotFoundException in this case but just returns the UserTransaction instance (according to the glassfish guys, a NameNotFoundException should only be thrown when lookup is done via "java:comp/..." (see https://glassfish.dev.java.net/issues/show_bug.cgi?id=3356)). When later on getStatus() is called on the retrieved UserTransaction instance, following exception is thrown: java.lang.IllegalStateException: Operation not allowed. at com.sun.enterprise.distributedtx.UserTransactionImpl.checkUserTransactionMethodAccess(UserTransactionImpl.java:135) at com.sun.enterprise.distributedtx.UserTransactionImpl.getStatus(UserTransactionImpl.java:262) at org.jboss.seam.transaction.UTTransaction.getStatus(UTTransaction.java:70) at org.jboss.seam.transaction.AbstractUserTransaction.isActive(AbstractUserTransaction.java:24) at org.jboss.seam.persistence.ManagedPersistenceContext.joinTransaction(ManagedPersistenceContext.java:120) at org.jboss.seam.persistence.ManagedPersistenceContext.getEntityManager(ManagedPersistenceContext.java:111) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.seam.util.Reflections.invoke(Reflections.java:21) at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:124) at org.jboss.seam.Component.callComponentMethod(Component.java:1975) at org.jboss.seam.Component.unwrap(Component.java:2001) at org.jboss.seam.Component.getInstance(Component.java:1788) at org.jboss.seam.Component.getInstance(Component.java:1741) at org.jboss.seam.Component.getValueToInject(Component.java:2026) at org.jboss.seam.Component.injectAttributes(Component.java:1499) at org.jboss.seam.Component.inject(Component.java:1320) When we change the implementation of getUserTransaction() to: (why isn't this the default implementation anyway??) protected javax.transaction.UserTransaction getUserTransaction() throws NamingException { return (javax.transaction.UserTransaction) Naming.getInitialContext().lookup(STANDARD_USER_TRANSACTION_NAME); } a NameNotFoundException is thrown, and a CMTTransaction is created in the getTransaction() method. However, then following exception is thrown: java.lang.IllegalStateException: ERROR: only SessionBeans with bean-managed transactionscan obtain UserTransaction at com.sun.ejb.containers.BaseContainer.getUserTransaction(BaseContainer.java:752) at com.sun.ejb.containers.SessionContextImpl.getUserTransaction(SessionContextImpl.java:198) at org.jboss.seam.transaction.CMTTransaction.getStatus(CMTTransaction.java:92) at org.jboss.seam.transaction.AbstractUserTransaction.isActive(AbstractUserTransaction.java:24) at org.jboss.seam.jsf.SeamPhaseListener.commitOrRollback(SeamPhaseListener.java:576) at org.jboss.seam.jsf.SeamPhaseListener.handleTransactionsAfterPhase(SeamPhaseListener.java:325) at org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:226) at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:184) at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:280) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) Even worse, an endless redirect happens then, due to the ExceptionHandler responsible for an IllegalStateException.