[
https://issues.apache.org/jira/browse/DELTASPIKE-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966697#comment-16966697
]
Mark Struberg edited comment on DELTASPIKE-1395 at 11/4/19 8:05 PM:
--------------------------------------------------------------------
This is clearly an implementation issue in Weld or rather Wildfly.
Weld should not drop your original bean for the whole EAR and just provide it
in the WAR. This is simply broken and not the thing we require by the
specification!
The specification is not quite clear how to implement those cases, but
specialisation rules are 'per module' as defined in the section "19.1.
Modularity in Java EE"
{quote}In the Java EE module architecture, a bean class is accessible in a
module if and only if it is required to be accessible according to the class
loading requirements defined by the Java EE platform specification.
{quote}
The problem is that Wildfly (and also IBM WebSphere) completely ignore ANY
classloader visibility in EARs. Those things used to work in Wildfly6 and
WebSphere-8.0 and 8.5 but got broken in later versions.
There is right now no way to solve this for users other than to drop EARs
alltogether and switch to WARs.
Or move to TomEE. TomEE has 1 BeanManager corresponding to each ClassLoader.
And they also form a tree which is symmetric to the ClassLoader tree.
was (Author: struberg):
This is clearly an implementation issue in Weld or rather Wildfly.
Weld should not drop your original bean for the whole EAR and just provide it
in the WAR. This is simply broken and not the thing we defined in the
specification!
The specification is not quite clear how to implement those cases, but
specialisation rules are 'per module' as defined in the section "19.1.
Modularity in Java EE"
{quote}In the Java EE module architecture, a bean class is accessible in a
module if and only if it is required to be accessible according to the class
loading requirements defined by the Java EE platform specification.
{quote}
The problem is that Wildfly (and also IBM WebSphere) completely ignore ANY
classloader visibility in EARs. Those things used to work in Wildfly6 and
WebSphere-8.0 and 8.5 but got broken in later versions.
There is right now no way to solve this for users other than to drop EARs
alltogether and switch to WARs.
Or move to TomEE. TomEE has 1 BeanManager corresponding to each ClassLoader.
And they also form a tree which is symmetric to the ClassLoader tree.
> 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)
