[
https://issues.apache.org/jira/browse/DELTASPIKE-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Mourgues updated DELTASPIKE-1395:
----------------------------------------
Description:
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.
was:
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.
> 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,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)
