[jboss-jira] [JBoss JIRA] (WFLY-9488) WeldDeployment initialisation error causes session fail-over to fail.

[Klaasjan Brand (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-9488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Klaasjan Brand updated WFLY-9488:
---------------------------------
    Description: 
At Topicus we've tested one of our Java EE applications to check compatibility with Wildfly session replication. This resulted in deserialization errors when performing a failover test.
(WELD-001122: Failed to deserialize annotated type identified with AnnotatedTypeIdentifier)
The application is deployed as an EAR archive containing several modules, one of them a WAR which hosts the main web frontend.
Point of interest is our application uses Wicket (with Wicket-CDI) to inject CDI resources in Wicket pages.

After a debugging session we concluded the "tryToLoadUnknownBackedAnnotatedType" method in the Weld class "SlimAnnotatedType" uses the wrong ResourceLoader when trying to load the class containing an injected object.

Further debugging proved the initialisation in the WeldDeployment method "createAndRegisterAdditionalBeanDeploymentArchive" copies all of the ServiceRegistry entries of the parent BeanDeployment to the child, overwriting the already set ResourceLoader.

I've attached a patch which prevents the overwriting of the deployment's already set entries. This fixed the replication problems with our application.


  was:
At Topicus we've tested one of our Java EE applications to check compatibility with Wildfly session replication. This resulted in deserialization errors when performing a failover test.
(WELD-001122: Failed to deserialize annotated type identified with AnnotatedTypeIdentifier)
The application is deployed as an EAR archive containing several modules, one of them a WAR which hosts the main web frontend.
Point of interest is our application uses Wicket (with Wicket-CDI) to inject CDI resources in Wicket pages.

After a debugging session we concluded the "tryToLoadUnknownBackedAnnotatedType" method in the Weld class "SlimAnnotatedType" uses the wrong ResourceLoader when trying to load the class containing an injected object.

Further debugging proved the initialisation in the WeldDeployment method "createAndRegisterAdditionalBeanDeploymentArchive" copies all of the ServiceRegistry entries of the parent BeanDeployment to the child, overwriting the already set ResourceLoader.




> WeldDeployment initialisation error causes session fail-over to fail.
> ---------------------------------------------------------------------
>
>                 Key: WFLY-9488
>                 URL: https://issues.jboss.org/browse/WFLY-9488
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 11.0.0.Final
>         Environment: Testen on OS X Sierra with Oracle JDK 1.8.0_152
>            Reporter: Klaasjan Brand
>            Assignee: Martin Kouba
>         Attachments: serviceregistry.patch
>
>
> At Topicus we've tested one of our Java EE applications to check compatibility with Wildfly session replication. This resulted in deserialization errors when performing a failover test.
> (WELD-001122: Failed to deserialize annotated type identified with AnnotatedTypeIdentifier)
> The application is deployed as an EAR archive containing several modules, one of them a WAR which hosts the main web frontend.
> Point of interest is our application uses Wicket (with Wicket-CDI) to inject CDI resources in Wicket pages.
> After a debugging session we concluded the "tryToLoadUnknownBackedAnnotatedType" method in the Weld class "SlimAnnotatedType" uses the wrong ResourceLoader when trying to load the class containing an injected object.
> Further debugging proved the initialisation in the WeldDeployment method "createAndRegisterAdditionalBeanDeploymentArchive" copies all of the ServiceRegistry entries of the parent BeanDeployment to the child, overwriting the already set ResourceLoader.
> I've attached a patch which prevents the overwriting of the deployment's already set entries. This fixed the replication problems with our application.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)