Uploaded image for project: 'Weld'
  1. Weld
  2. WELD-975

Programmatic lookup with @New qualifier not working

    Details

    • Similar Issues:
      Show 10 results 

      Description

      According to spec: "...the @New qualifier may be used, allowing the application to obtain a @New qualified bean, as defined in Section 3.12, @New qualified beans" (CDI 1.0; chapter 5.6. Programmatic lookup).

      However using programmatic lookup with @New qualifier like:

      @Inject @New Instance<Foo> foo;
      

      results in:

      org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308 Unable to resolve any beans for Types: [class org.jboss.cditck.arquillian.instance.Foo]; Bindings: [@javax.enterprise.inject.New(value=org.jboss.cditck.arquillian.instance.Foo.class)]
      

      after trying to obtain reference via get() method.

      Following code works ok:

      @Inject @New Foo foo;
      

        Gliffy Diagrams

          Activity

          Hide
          swd847 Stuart Douglas added a comment -

          I'm not really sure if this is allowed by the current spec. We should probably clarify if this is actually allowed.

          Show
          swd847 Stuart Douglas added a comment - I'm not really sure if this is allowed by the current spec. We should probably clarify if this is actually allowed.
          Hide
          mkouba Martin Kouba added a comment -

          Current spec states even more complicated example (page 47):

          @Inject @New(ChequePaymentProcessor.class) Instance<PaymentProcessor> chequePaymentProcessor;
          

          Show
          mkouba Martin Kouba added a comment - Current spec states even more complicated example (page 47): @Inject @New(ChequePaymentProcessor.class) Instance<PaymentProcessor> chequePaymentProcessor;
          Hide
          chrikru Christian Fechner added a comment -

          I investigated this issue a little bit and found following:

          This is an example, that is currently not working:

          ...
          @SessionScoped
          public class SomeBean {
           
          @Inject @New
          Instance<SomeBean2> someBean2Provider;
          }
          ...
          

          However, this is working:

          ...
          @SessionScoped
          public class SomeBean {
           
          @Inject @New
          SomeBean2 someBean2;
           
          @Inject @New
          Instance<SomeBean2> someBean2Provider;
          }
          ...
          

          It seems that in the second case WELD is satisfied, cause it could resolve the dependency due to the additional "normal" injection.

          While this may be a workaround for many cases, it does not work for the following example, where a bean wants to inject an instance of itself:

          ...
          @SessionScoped
          public class SomeBean {
           
          @Inject @New
          Instance<SomeBean> someBeanProvider;
          }
          ...
          

          Applying the workaround here would correctly result in an error due to a circular dependency. But the example itself is valid, cause the someBeanProvider can be used to inject 0-n instances of the bean, so that the recursion can be avoided programatically.
          Such construction occurs for example, when a tree of beans should be constructed dynamically depending on database content, which also represents a tree structure.

          So when fixing the resolving for the "@Inject @New Instance<SomeBean>" case, it must be ensured, that the validation does not complain about a circular dependency.

          Show
          chrikru Christian Fechner added a comment - I investigated this issue a little bit and found following: This is an example, that is currently not working: ... @SessionScoped public class SomeBean {   @Inject @New Instance<SomeBean2> someBean2Provider; } ... However, this is working: ... @SessionScoped public class SomeBean {   @Inject @New SomeBean2 someBean2;   @Inject @New Instance<SomeBean2> someBean2Provider; } ... It seems that in the second case WELD is satisfied, cause it could resolve the dependency due to the additional "normal" injection. While this may be a workaround for many cases, it does not work for the following example, where a bean wants to inject an instance of itself: ... @SessionScoped public class SomeBean {   @Inject @New Instance<SomeBean> someBeanProvider; } ... Applying the workaround here would correctly result in an error due to a circular dependency. But the example itself is valid, cause the someBeanProvider can be used to inject 0-n instances of the bean, so that the recursion can be avoided programatically. Such construction occurs for example, when a tree of beans should be constructed dynamically depending on database content, which also represents a tree structure. So when fixing the resolving for the "@Inject @New Instance<SomeBean>" case, it must be ensured, that the validation does not complain about a circular dependency.
          Hide
          alesj Ales Justin added a comment -

          Jozef, feel free to re-assign later.

          Show
          alesj Ales Justin added a comment - Jozef, feel free to re-assign later.

            People

            • Assignee:
              jharting Jozef Hartinger
              Reporter:
              mkouba Martin Kouba
            • Votes:
              1 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development