OpenWebBeans
  1. OpenWebBeans
  2. OWB-658

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

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.3
    • Fix Version/s: 1.1.4
    • Component/s: Injection and Lookup
    • Labels:
      None

      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)

        Activity

        Hide
        Mark Struberg added a comment -

        txs 4 the report! I'll dig into this in the next few days. In any case before our upcoming 1.1.4 release.

        Show
        Mark Struberg added a comment - txs 4 the report! I'll dig into this in the next few days. In any case before our upcoming 1.1.4 release.
        Hide
        Mark Struberg added a comment -

        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.

        Show
        Mark Struberg added a comment - 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.
        Hide
        Mark Struberg added a comment -

        can you please try with the latest SNAPSHOT? The behaviour is not yet final as we need to specify the correct behaviour in the EG first.

        Show
        Mark Struberg added a comment - can you please try with the latest SNAPSHOT? The behaviour is not yet final as we need to specify the correct behaviour in the EG first.
        Hide
        Andreas Erne added a comment -

        I tested the 1.1.4-SNAPSHOT and found the results promising but by far not "fixed". Therefore I'd like to reopen this issue.

        Show
        Andreas Erne added a comment - I tested the 1.1.4-SNAPSHOT and found the results promising but by far not "fixed". Therefore I'd like to reopen this issue.
        Hide
        Mark Struberg added a comment -

        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.

        Show
        Mark Struberg added a comment - 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.
        Hide
        Andreas Erne added a comment -

        Our case is even simpler than the one you described:

        >public class @Service MyBeanA extends BaseBean implements A ...
        >public class @Service MyBeanB extends BaseBean implements B ...
        >public class @Service @Alternative MyBeanBAlt extends BaseBean implements B ...

        beanManager.getBeans(BaseBean.class, new ServiceQualifier()) should return MyBeanA and MyBeanBAlt

        I understand that it is quite hard to define for which bean type filter criteria an alternative should be evaluated or not. For example:

        >Example 1: beanManager.getBeans(Object.class)
        >Example 2: beanManager.getBeans(BaseBean.class)
        >Example 3: beanManager.getBeans(A.class)
        >...

        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.

        Show
        Andreas Erne added a comment - Our case is even simpler than the one you described: >public class @Service MyBeanA extends BaseBean implements A ... >public class @Service MyBeanB extends BaseBean implements B ... >public class @Service @Alternative MyBeanBAlt extends BaseBean implements B ... beanManager.getBeans(BaseBean.class, new ServiceQualifier()) should return MyBeanA and MyBeanBAlt I understand that it is quite hard to define for which bean type filter criteria an alternative should be evaluated or not. For example: >Example 1: beanManager.getBeans(Object.class) >Example 2: beanManager.getBeans(BaseBean.class) >Example 3: beanManager.getBeans(A.class) >... 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.
        Hide
        Mark Struberg added a comment -

        > 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.

        Show
        Mark Struberg added a comment - > 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.
        Hide
        Mark Struberg added a comment -

        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!

        Show
        Mark Struberg added a comment - 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!
        Hide
        Mark Struberg added a comment -

        released with OWB-1.1.4

        Show
        Mark Struberg added a comment - released with OWB-1 .1.4

          People

          • Assignee:
            Mark Struberg
            Reporter:
            Andreas Erne
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development