[
https://issues.jboss.org/browse/WFLY-9488?page=com.atlassian.jira.plugin....
]
Klaasjan Brand commented on WFLY-9488:
--------------------------------------
Our deployment structure is an ear bundle containing (among other artifacts) a Wicket
webapp:
bundle.ear
\_ webapp.war
(contains the application as a jar package under /WEB-INF/lib/app-core.jar)
The webapp components as well as most of the injected beans (and certainly some with which
I could reproduce this issue) are defined in the 'app-core' jar.
I can't find any definitive description of 'additional deployment'; is my
assumption that the 'app-core.jar' is an additional deployment of the webapp.war
correct?
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)