[
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)
