|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
_______________________________________________ weld-issues mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-issues
That's just the thing. I couldn't reproduce the problem on JBossAS, that's why I needed WLS. Anyway, I upgraded Weld on WLS and was able to reproduce the problem. I can confirm that this is definitely a Weld bug.
When a bean manager finds a specializing bean, it register the specializing bean in all bean managers that are accessible from it. When the EJB jar's bean manager finds MockAccountBean, it doesn't register it with the WAR's bean manager, since the WAR's bean manager isn't accessible from the EJB jar's bean manager. Therefore the WAR's bean manager sees both MockAccountBean and AccountBean and since the latter isn't disabled, there are indeed two beans that can be injected into the injection point (NOTE: the injection point is inside the WAR)
It works on JBossAS simply because JBossAS sets up an additional BDA called "additionalClasses". This BDA can see all other BDAs and all other BDAs see it. Therefore the WAR's bean manager is transitively accessible from the EJB jar's bean manager via additionalClasses. Of course it shouldn't be.
The reason why this works on Weld 2 is because Weld 2 keeps a global specialization registry. When a bean specializes another bean in any BDA, all other BDAs know about it. IMHO this is also wrong, since it will cause an UnresolvedDependencyException when the specialized bean is in the EJB jar, the specializing bean is in the WAR and there is an injection point in the EJB jar. In such a case, AccountBean would be disabled, but MockAccountBean would not be visible in the EJB jar, therefore there would be no beans eligible for injection inside the EJB jar.
It looks like the only sensible thing to do is keep the specialization info per bean manager, but make sure that instead of notifying all accessible bean managers about the specialization, we should notify only those bean managers that the bean manager holding the specializing bean is accessible from.
We should also re-examine the additionalClasses BDA.