[jboss-jira] [JBoss JIRA] (WFLY-1705) JPA persistence units make use of SerializableValidatorFactory instead of using the JNDI bound default ValidatorFactory

[Farah Juma (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805197#comment-12805197 ] 

Farah Juma commented on WFLY-1705:
----------------------------------

I've verified that the Hibernate ORM component upgrade that was just merged into wildfly master (WFLY-2056) now allows my tests for WFLY-1705 to pass. (Hibernate ORM 4.3.0.Beta4 contains a fix for a bug I found related to org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl#withValidatorFactory. For more details, see https://hibernate.atlassian.net/browse/HHH-8492).

However, I'm now seeing 2 EJB failures in the WildFly testsuite. In particular, org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientUserTransactionTestCase#testBatchOperationsInTx and org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientXidTransactionTestCase#testClientTransactionManagement are failing as follows:

{code}
java.lang.RuntimeException: javax.transaction.
RollbackException: ARJUNA016053: Could not commit transaction.
        at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.sendCommit(RemotingConnectionEJBReceiver.java:366)
        at org.jboss.ejb.client.EJBClientUserTransactionContext$UserTransactionImpl.commit(EJBClientUserTransactionContext.java:128)
        at org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientUserTransactionTestCase.testBatchOperationsInTx(EJBClientUserTransactionTestCase.java:168)
...
Caused by: javax.persistence.PersistenceException: error during managed flush
        at org.hibernate.jpa.spi.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1785)
        at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:118)
        at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53)
        at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
        at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
        at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
...
Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for ModuleClassLoader for Module "org.wildfly.extension.io:main" from local module loader @4b144220 (finder: local module finder @1f016962 (roots: /home/fjuma/Documents/wildfly/sept9wildfly/wildfly/testsuite/integration/basic/../../../build/target/wildfly-8.0.0.Beta1-SNAPSHOT/modules,/home/fjuma/Documents/wildfly/sept9wildfly/wildfly/testsuite/integration/basic/../../../build/target/wildfly-8.0.0.Beta1-SNAPSHOT/modules/system/layers/base,/home/fjuma/Documents/wildfly/sept9wildfly/wildfly/testsuite/integration/basic/target/modules)). 
This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
        at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
        at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
        at org.jboss.weld.Container.instance(Container.java:65)
        at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:75)
        at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:99)
        at org.jboss.weld.proxies.ValidatorFactory$618047133$Proxy$_$$_WeldClientProxy.usingContext(Unknown Source)
        at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.usingContext(LazyValidatorFactory.java:89)
{code}

Note that the wrong ModuleClassLoader is being used for some reason now that JPA is using the EE LazyValidatorFactory instead of the JPALazyValidatorFactory. I'll continue looking into this to determine how to fix these failures. Interestingly, the same exception (i.e., "Singleton not set for ModuleClassLoader...This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment") was also mentioned in a recent PR by Paul Ferraro: https://github.com/wildfly/wildfly/pull/5018. 
                
> JPA persistence units make use of SerializableValidatorFactory instead of using the JNDI bound default ValidatorFactory
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1705
>                 URL: https://issues.jboss.org/browse/WFLY-1705
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Hardy Ferentschik
>            Assignee: Farah Juma
>
> I think there is no need for {{SerializableValidatorFactory}}. _LazyValidatorFactory_ should be used at all times to also ensure that CDI injection works.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira