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;
      

        Activity

        Hide
        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
        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
        Martin Kouba
        added a comment -

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

        @Inject @New(ChequePaymentProcessor.class) Instance<PaymentProcessor> chequePaymentProcessor;
        
        Show
        Martin Kouba
        added a comment - Current spec states even more complicated example (page 47): @Inject @New(ChequePaymentProcessor.class) Instance<PaymentProcessor> chequePaymentProcessor;
        Hide
        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
        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
        Ales Justin
        added a comment -

        Jozef, feel free to re-assign later.

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

          People

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

            Dates

            • Created:
              Updated:
              Resolved: