Details
-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Critical
-
Resolution: Done
-
Affects Version/s: 1.1.2.Final
-
Fix Version/s: 1.1.4.Final
-
Component/s: None
-
Labels:None
Description
See pull request with testcase.
@ApplicationScoped
|
@Named("namedFoo") // doesn't matter if it's @Named or not
|
public class NamedFoo
|
{
|
|
|
}
|
|
|
@Alternative @Specializes
|
public class SpecializesNamedFoo extends NamedFoo
|
{
|
|
|
}
|
|
|
|
|
@Test
|
public void testSpecializationWithAlternative()
|
{
|
Assert.assertEquals(NamedFoo.class, beanManager.resolve(beanManager.getBeans(NamedFoo.class)).getBeanClass()); // FAILS WITH NPE!
|
}
|
Gliffy Diagrams
Issue Links
- relates to
-
WELD-973
@Specializes is not compatible with seam-config because of a problem in weld's BeanDeployerEnvironment
-
- Resolved
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
Geoffrey,
First, I assume you'd like to resolve your SpecializesNamedFoo, not NamedFoo?
@Test
|
public void testSpecializationWithAlternative() {
|
Assert.assertEquals(SpecializesNamedFoo.class, beanManager.resolve(beanManager.getBeans(NamedFoo.class)).getBeanClass());
|
}
|
Second, I believe the behavior is expected, because according to the spec, alternatives should be by default disabled unless you enable them in beans.xml. So if I modify your test case to reflect this, it passes the test:
@Deployment
|
public static Archive<?> deploy() {
|
return ShrinkWrap.create(BeanArchive.class)
|
.alternate(SpecializesNamedFoo.class)
|
.addPackage(SpecializationTest.class.getPackage());
|
}
|
Or?
br,
Jens
Jens Augustsson
added a comment - Geoffrey,
First, I assume you'd like to resolve your SpecializesNamedFoo, not NamedFoo?
@Test
public void testSpecializationWithAlternative() {
Assert.assertEquals(SpecializesNamedFoo.class, beanManager.resolve(beanManager.getBeans(NamedFoo.class)).getBeanClass());
}
Second, I believe the behavior is expected, because according to the spec, alternatives should be by default disabled unless you enable them in beans.xml. So if I modify your test case to reflect this, it passes the test:
@Deployment
public static Archive<?> deploy() {
return ShrinkWrap.create(BeanArchive.class)
.alternate(SpecializesNamedFoo.class)
.addPackage(SpecializationTest.class.getPackage());
}
Or?
br,
Jens Hi Jens,
The alternative is deliberately not activated: the testcase should expect to get a NamedFoo.class instead, not a SpecializesNamedFoo.class.
The bug is that the presence of SpecalizesNamedFoo creates an NPE on
beanManager.resolve(beanManager.getBeans(NamedFoo.class))
|
Geoffrey De Smet
added a comment - Hi Jens,
The alternative is deliberately not activated: the testcase should expect to get a NamedFoo.class instead, not a SpecializesNamedFoo.class.
The bug is that the presence of SpecalizesNamedFoo creates an NPE on
beanManager.resolve(beanManager.getBeans(NamedFoo.class))
...ah, point taken!
Jens Augustsson
added a comment - ...ah, point taken! This is fixed in 1.1.4.Final, probably by Ales's work.
I 'll poke him to add the regression test to weld's master if he hasn't a similar one already.
Geoffrey De Smet
added a comment - This is fixed in 1.1.4.Final, probably by Ales's work.
I 'll poke him to add the regression test to weld's master if he hasn't a similar one already. 
Here's the pull request with the failing testcase:
https://github.com/weld/core/pull/134