BeanManager.getBeans(Type, Annotation...) can not be used to query all known beans

Details

Description

Expected behaviour: beanManager.getBeans(Object.class, new ServiceQualifier()) finds all beans that are qualified as "Service", regardless of the beans implementation type

Effective behaviour: The BeanManager fails if a base type (Object in this example) is provided instead of a leaf type. In theses cases, the BeanManager finds the Alternative beans only and forgets about all beans that lack of an Alternative

Reason: The BeanManager's helper org.apache.webbeans.container.InjectionResolver fails in method implResolveByType method as it can not handle collections of beans of different types. It treats all beans as if they where of the same type (and therefore have the same Alternative)

Mark Struberg
added a comment - 04/Apr/12 16:55 oki, back from talking with Pete. 5.1 defines 'available for injection' and 11.3.4 specifies that getBeans() only returns beans which are available for injection.
getBeans(TypeX) only resolves beans which are enabled for filling an InjetionPoint of TypeX!

> beanManager.getBeans(BaseBean.class, new ServiceQualifier()) should return MyBeanA and MyBeanBAlt
nope, because MyBeanBAlt is also an @Alternative for MyBeanA. (because of the extends BaseBean).

MyBeanBAlt + MyBeanA would only be returned if MyBeanBAlt would NOT extend BaseBean.

And yes, filter criterias are a region where we certainly need to take care off in the spec. I'm also not 100% sure if BeanManager#getBeans() or BeanManager#resolve() should perform this part of the filtering. I'll discuss this with the colleagues in the EG.

Mark Struberg
added a comment - 04/Apr/12 15:15 > beanManager.getBeans(BaseBean.class, new ServiceQualifier()) should return MyBeanA and MyBeanBAlt
nope, because MyBeanBAlt is also an @Alternative for MyBeanA. (because of the extends BaseBean).
MyBeanBAlt + MyBeanA would only be returned if MyBeanBAlt would NOT extend BaseBean.
And yes, filter criterias are a region where we certainly need to take care off in the spec. I'm also not 100% sure if BeanManager#getBeans() or BeanManager#resolve() should perform this part of the filtering. I'll discuss this with the colleagues in the EG.

One solution could be to return all matching beans (inclusive alternatives) if the bean type filter criteria is not an interface (examples 1 and 2). For example 3, the alternatives for A are evaluated.

Please put some ham in it. I need either a concrete example or a unit test which shows what is wrong.

The constellation you reported initially (query for Object.class + Classifier) works now, isn't?
If so then please create a follow up issue and set this one to resolved.
The reason is that I like to start the 1.1.4 release tonight, and it is impossible to track those issues otherwise.

Mark Struberg
added a comment - 04/Apr/12 14:50 Please put some ham in it. I need either a concrete example or a unit test which shows what is wrong.
The constellation you reported initially (query for Object.class + Classifier) works now, isn't?
If so then please create a follow up issue and set this one to resolved.
The reason is that I like to start the 1.1.4 release tonight, and it is impossible to track those issues otherwise.

Mark Struberg
added a comment - 01/Apr/12 11:01 This might need some bigger change. In case of an isAlternative(), we should also store for which types! This is typically needed if a
> public class MyBean implements ServiceA, ServiceB {};
> public class @Alternative MyAlternative implements ServiceA
Thus for
> private @Inject ServiceA a;
you will get an instance of MyAlternative.
But for
> private @Inject ServiceB b;
you will get an instance of MyBean.