Xavier Mourgues created DELTASPIKE-1395:
-------------------------------------------
Summary: specialized bean in jsf module are not available to EAR
layer in wildfly 18
Key: DELTASPIKE-1395
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1395
Project: DeltaSpike
Issue Type: Bug
Security Level: public (Regular issues)
Components: JSF-Module
Affects Versions: 1.9.1
Environment: jboss EAP 7.2.4 / wildfly 18.0.0.Final
Reporter: Xavier Mourgues
Hello,
This is a follow-up of an [issue open to jboss
weld|https://issues.jboss.org/browse/WELD-2601].
When using deltaspike-core in an EAR and deltaspike-jsf-module in a WAR, there
are some unsatisfied dependencies
{code:java}
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied
dependencies for type LocaleResolver with qualifiers @Default
at injection point [BackedAnnotatedField] @Inject private
org.apache.deltaspike.core.impl.message.DefaultMessageContext.localeResolver
at
org.apache.deltaspike.core.impl.message.DefaultMessageContext.localeResolver(DefaultMessageContext.java:0)
at
org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:378)
at
org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:290)
at
org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:143)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526)
at
org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64)
at
org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62)
at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
{code}
This is due to the use of @Specialized bean being in a module (the war) not
visible/accessible by the injection point being in the EAR.
On EAP 6.4 or jboss AS 7, after trying some simple use case, it appears that
the resolved bean was always the @Specialized bean whether or not it was
injected in the EAR layer or in the WAR layer. => I'm not sure this was the
correct behavior anyway but it allowed the application to be deployed.
On EAP 7.2.4 or wildfly 18.0.0.Final, the application doesn't even deploy due
to the DeploymentException shown above.
----
As a workaround, one can set-up a dependency from the ear deployment to the war
subdeployment in the jboss-deployment-structure.xml (see below) but this break
the EE spec as it gives the visibility of the war module to every other module
in the application.
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
<ear-subdeployments-isolated>true</ear-subdeployments-isolated>
<deployment>
<dependencies>
<module name="deployment.sample-ear-1.0.0.ear.sample-web-1.0.0.war"
export="true"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
{code}
----
After some more test, it seems that using an @Alternative (and setting up in
the beans.xml of the jsf-module web-fragment) in place of @Specialize would not
cause a deployment problem but have the following behavior
On EAP 7 / wildfly 18, injections point in the EAR are resolved to the
"non-alternative" bean and injections point in the WAR are resolved to the
@Alternative one => This looks like the coherent behavior
On EAP 6 / AS 7, injections point in the EAR and in the WAR are bot resolved to
the "non-alternative" bean => This isn't coherent, like with the @Specialize
issue on this environment but in a different way which would probably fail some
regression tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
