[jira] [Created] (DELTASPIKE-1395) specialized bean in jsf module are not available to EAR layer in wildfly 18

["Xavier Mourgues (Jira)" <ji...@apache.org>]

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)