Search code examples
javajakarta-eewildflycdijta

CDI / JTA - Error during session replication: UnproxyableResolutionException

I am testing server failover in a Wildfly 26 cluster (using standalone-ha.xml config)

The application is a stateful JSF / Jakarta EE8 / CDI war deployment

We are using Deltaspike Data and JPA modules in DAO pattern (with @RequestScoped entity managers)

I have two nodes runnings 1 and 2 and perform the following steps:

  • Login to a user account on Node 1 to create some session data.
  • Perform a graceful shutdown of Node 1, logs show Node 1 has left the cluster and is reported in logs at Node 2
  • Refresh browser
  • Node 2 loads the replication session data then throws the exception pasted below to say that com.arjuna.ats.jta.cdi.DelegatingTransactionManager is not proxyable. The page doesn't render any content and I have to start a new HTTP session to be able to continue on Node 2

[0m [31m11:31:47,479 ERROR [io.undertow.servlet.request] (default task-2) UT015005: Error invoking method requestInitialized on listener class org.jboss.weld.module.web.servlet.WeldInitialListener: org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001435: Normal scoped bean class com.arjuna.ats.jta.cdi.DelegatingTransactionManager is not proxyable because it has no no-args constructor - Managed Bean [class com.arjuna.ats.jta.cdi.NarayanaTransactionManager] with qualifiers [@Any @Default].

Further down it references one of our CDI @ViewScoped beans (ManageCheers):

Caused by: an exception which occurred: in object of type org.jboss.weld.bean.proxy.util.SerializableClientProxy in field com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.transactionManager in object com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired@2cbfe004 in object of type com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired in field org.jboss.weld.interceptor.proxy.InterceptionContext.interceptorInstances in object org.jboss.weld.interceptor.proxy.InterceptionContext@7ce2923f in object of type org.jboss.weld.interceptor.proxy.InterceptionContext in field org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.ctx in object org.jboss.weld.interceptor.proxy.InterceptorMethodHandler@651c0cb2 in object of type org.jboss.weld.interceptor.proxy.InterceptorMethodHandler in field org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.interceptorMethodHandler in object org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler@36f06fd5 in object of type org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler in field com.myapp.actions.notifications.ManageCheers$Proxy$_$$WeldSubclass.methodHandler in object com.myapp.actions.notifications.ManageCheers$Proxy$$$WeldSubclass@4e106109 in object of type com.myapp.actions.notifications.ManageCheers$Proxy$$$_WeldSubclass in object of type javax.faces.component.UIViewRoot$ViewMap in object of type com.sun.faces.util.LRUMap

-----UPDATE

The problem seems to be linked to the

@Transactional(Transactional.TxType.REQUIRED)

annotation, if I remove this annotation from our CDI bean it does not occur, but then we have no transactions.

I notice that NarayanaTransactionManager is @ApplicationScoped so maybe the server shutdown is causing it to be re-created?

Solution

  • This seems to be a bug in Narayana, I forked the library and added a no-args constructor to the DelegatingTransactionManager and the exception no longer occurs.

    Bug reported here:

    https://issues.redhat.com/projects/JBTM/issues/JBTM-3703?filter=allopenissues