Details
-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Major
-
Resolution: Done
-
Affects Version/s: 1.1.2.Final
-
Fix Version/s: 1.1.4.Final
-
Component/s: None
-
Labels:None
Description
BeanDeployerEnvironment has 2 methods which - combined with seam-config - break @Specializes:
public class BeanDeployerEnvironment {
|
|
|
private final Map<WeldClass<?>, AbstractClassBean<?>> classBeanMap;
|
|
|
protected void addAbstractClassBean(AbstractClassBean<?> bean)
|
{
|
...
|
classBeanMap.put(bean.getWeldAnnotated(), bean);
|
...
|
}
|
|
|
public AbstractClassBean<?> getClassBean(WeldClass<?> clazz)
|
{
|
if (!classBeanMap.containsKey(clazz))
|
{
|
return null;
|
}
|
...
|
}
|
|
Here's what happens:
In this use case I have a bean RepositoryStartupService, which is extra configured by seam-config.
It is also specialized by TestRepositoryStartupService (for tests).
1) First addAbstractClassBean is called with these parameters:
bean = Managed Bean [class org.drools.guvnor.server.repository.RepositoryStartupService] with qualifiers [@Any @Default @Named]
|
bean.bean.getWeldAnnotated() = public@Named @XmlConfiguredBean @ApplicationScoped @XmlId class org.drools.guvnor.server.repository.RepositoryStartupService
|
2) Later on, getClassBean is called to find the parent class RepositoryStartupService:
clazz = public@Named @ApplicationScoped class org.drools.guvnor.server.repository.RepositoryStartupService
|
which returns null because the @XmlConfiguredBean bits are missing.
So I get this exception message:
org.jboss.weld.exceptions.DefinitionException: WELD-000047 Specializing bean must extend another bean: Managed Bean [class org.drools.guvnor.server.repository.TestRepositoryStartupService] with qualifiers [@Any @Default]
|
One can argue that since seam-config is not configuring TestRepositoryStartupService a failure is normal,
but even in that case the exception message is very misleading, as looking at the code TestRepositoryStartupService clearly extends RepositoryStartupService which is also a bean.
Gliffy Diagrams
Issue Links
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
I think that this is related to the other @Specializes problems, I think we are going to need to re-write a good part of the @Specializes code anyway, and we should make sure this is fixed in the re-write.
Stuart Douglas
added a comment - I think that this is related to the other @Specializes problems, I think we are going to need to re-write a good part of the @Specializes code anyway, and we should make sure this is fixed in the re-write. This might also be caused by SOLDER-220 (which is my number 1 issue in seam-weld)
Geoffrey De Smet
added a comment - This might also be caused by SOLDER-220 (which is my number 1 issue in seam-weld) @Geoffrey: can you try my Weld Core branch weld-912, to see if the issue is still there?
(https://github.com/alesj/core/tree/weld-912)
Ales Justin
added a comment - @Geoffrey: can you try my Weld Core branch weld-912, to see if the issue is still there?
( https://github.com/alesj/core/tree/weld-912 ) Weld 1.1.4.Final seems to have fixed this issue, tnx 
Here's what I tested and works:
- @ApplicationScoped RepositoryStartupService is changed with seam-solder-config
- @Alternative @Specializes TestRepositoryStartupService extends RepositoryStartupService is in the classpath too (not activated), but this is not a problem.
- In my tests, TestRepositoryStartupService is activated and RepositoryStartupService doesn't need to be configured by seam-solder-config.
Geoffrey De Smet
added a comment - Weld 1.1.4.Final seems to have fixed this issue, tnx
Here's what I tested and works:
@ApplicationScoped RepositoryStartupService is changed with seam-solder-config
@Alternative @Specializes TestRepositoryStartupService extends RepositoryStartupService is in the classpath too (not activated), but this is not a problem.
In my tests, TestRepositoryStartupService is activated and RepositoryStartupService doesn't need to be configured by seam-solder-config.
Note the far-reaching effect of this issue:
Any bean that is specialized by or specializes another bean cannot be configured by seam-config.
If @Specializes is used and 1 of the 2 involved beans is seam-configured, weld crashes always (even if the subclass is an @Alternative).