[ https://issues.apache.org/jira/browse/DELTASPIKE-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966613#comment-16966613 ]
Thomas Andraschko commented on DELTASPIKE-1395: ----------------------------------------------- Is this really a bug? The weld issue states that it works like expected? [~struberg] can you check this? > 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 > Priority: Major > > 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)