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

["Mark Struberg (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DELTASPIKE-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Struberg resolved DELTASPIKE-1395.
---------------------------------------
      Assignee: Mark Struberg
    Resolution: Not A Problem

Hi!

I'm sorry, but I have to close this ticket in DS. I think you hit an unspecified case in CDI. In general the whole EAR scenario is sadly not really well defined. Thus I understand why the Weld team did mark it as invalid as well. But from a user point of view it of course should work. Glad you at least found a workaround it seems.

> 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
>            Assignee: Mark Struberg
>            Priority: Major
>
> Hello,ettings
>   
>  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)