Details

    • Type: Feature Request
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 1.0
    • Fix Version/s: 1.1.EDR, 1.1.PRD
    • Component/s: Beans
    • Labels:
      None

      Gliffy Diagrams

        Issue Links

          Activity

          Hide
          rhigh Richard Hightower added a comment -

          It is hard to even consider this without some further explanation.
          Can you clarify? I went to the link. This needs more discussion.

          Show
          rhigh Richard Hightower added a comment - It is hard to even consider this without some further explanation. Can you clarify? I went to the link. This needs more discussion.
          Hide
          pmuir Pete Muir added a comment -

          Sometimes it is useful for a bean instance to be able to inject the Bean object which was used to instantiate it in order to inspect the metadata which defined it (it's qualifiers, it's name etc.) allowing:

          class Foo {
           
             @Inject Bean<Foo> metadata;
           
             ...
          }
          

          is a neat and concise way to do it.

          This is somewhat analagous to being able to inject the EJBContext.

          Show
          pmuir Pete Muir added a comment - Sometimes it is useful for a bean instance to be able to inject the Bean object which was used to instantiate it in order to inspect the metadata which defined it (it's qualifiers, it's name etc.) allowing: class Foo {   @Inject Bean<Foo> metadata;   ... } is a neat and concise way to do it. This is somewhat analagous to being able to inject the EJBContext.
          Hide
          rhigh Richard Hightower added a comment -

          Got it. Makes sense. Sort of like BeanNameAware in Spring.

          Show
          rhigh Richard Hightower added a comment - Got it. Makes sense. Sort of like BeanNameAware in Spring.
          Hide
          pmuir Pete Muir added a comment -
          Show
          pmuir Pete Muir added a comment - https://github.com/jboss/cdi/pull/53
          Hide
          jharting Jozef Hartinger added a comment -

          It seems that for an interceptor / decorator the injected object would be an instance of javax.enterprise.inject.spi.Interceptor/Decorator. Could we rather:

          1) state explicitly that a bean representing intercepted / decorated instance should be injected or
          2) support @Inject @Delegate Bean<?>

          Show
          jharting Jozef Hartinger added a comment - It seems that for an interceptor / decorator the injected object would be an instance of javax.enterprise.inject.spi.Interceptor/Decorator. Could we rather: 1) state explicitly that a bean representing intercepted / decorated instance should be injected or 2) support @Inject @Delegate Bean<?>
          Hide
          pmuir Pete Muir added a comment -

          This is a good idea, however I think we need to introduce a qualifier - @Delegate is not a qualifier. Any ideas on name?

          Show
          pmuir Pete Muir added a comment - This is a good idea, however I think we need to introduce a qualifier - @Delegate is not a qualifier. Any ideas on name?
          Hide
          marius.bogoevici Marius Bogoevici added a comment - - edited

          @Inject @Delegate means something else in the case of a Decorator anyway (and there's no delegate in the case of an interceptor). Also, I cannot see why there cannot be two separate concerns:

          a) Inject the bean (which in the case of an Interceptor/Decorator will inject the Interceptor/Decorator itself, they're beans too, nothing wrong with that)

          b) Inject the target instance or delegate. Since we don't have a common term for interception or decoration we could have two distinct qualifiers:

          @Inject @Intercepted Bean<?> bean; for interceptors

          @Inject @Decorated Bean<?> bean; for decorators

          One point against this would be the proliferation of annotations, but I think that using distinct annotations helps keeping the spec clear.

          Show
          marius.bogoevici Marius Bogoevici added a comment - - edited @Inject @Delegate means something else in the case of a Decorator anyway (and there's no delegate in the case of an interceptor). Also, I cannot see why there cannot be two separate concerns: a) Inject the bean (which in the case of an Interceptor/Decorator will inject the Interceptor/Decorator itself, they're beans too, nothing wrong with that) b) Inject the target instance or delegate. Since we don't have a common term for interception or decoration we could have two distinct qualifiers: @Inject @Intercepted Bean<?> bean; for interceptors @Inject @Decorated Bean<?> bean; for decorators One point against this would be the proliferation of annotations, but I think that using distinct annotations helps keeping the spec clear.
          Hide
          jharting Jozef Hartinger added a comment -

          Reopening, since multiple implications are not handled by this change.

          1.) The qualifiers (@Intercepted, @Decorated) are missing from the API and from the specification document.

          2.) Similarly to the Injection point metadata section, the Bean metadata section should name possible invalid scenarios and required the container to treat them as a definition error. These include:

          • Interceptor<?> injection point in a non-interceptor bean
          • @Intercepted Bean<?> injection point in a non-interceptor bean
          • Decorator<?> injection point in a non-decorator bean
          • @Decorated Bean<?> injection point in a non-decorator bean

          3.) The spec should define what happens in the following scenatio:

          class Foo {
             @Inject Bean<Bar> metadata;
          }
          

          Should the container validate the generic type of a bean metadata injection point? Should the abovementioned example be treated as a definiton error?

          4.) The spec should perhaps explicitly state that it is possible to inject bean metadata into a disposer method and that this metadata always refers to the producer field/method that created the instance being destroyed.

          Show
          jharting Jozef Hartinger added a comment - Reopening, since multiple implications are not handled by this change. 1.) The qualifiers (@Intercepted, @Decorated) are missing from the API and from the specification document. 2.) Similarly to the Injection point metadata section, the Bean metadata section should name possible invalid scenarios and required the container to treat them as a definition error. These include: Interceptor<?> injection point in a non-interceptor bean @Intercepted Bean<?> injection point in a non-interceptor bean Decorator<?> injection point in a non-decorator bean @Decorated Bean<?> injection point in a non-decorator bean 3.) The spec should define what happens in the following scenatio: class Foo { @Inject Bean<Bar> metadata; } Should the container validate the generic type of a bean metadata injection point? Should the abovementioned example be treated as a definiton error? 4.) The spec should perhaps explicitly state that it is possible to inject bean metadata into a disposer method and that this metadata always refers to the producer field/method that created the instance being destroyed.
          Hide
          pmuir Pete Muir added a comment -

          I removed the part baked stuff that should be addressed properly in CDI-42, and fixed the remaining points in https://github.com/jboss/cdi/pull/69

          Show
          pmuir Pete Muir added a comment - I removed the part baked stuff that should be addressed properly in CDI-42 , and fixed the remaining points in https://github.com/jboss/cdi/pull/69
          Hide
          pmuir Pete Muir added a comment -

          Merged changes.

          Show
          pmuir Pete Muir added a comment - Merged changes.

            People

            • Assignee:
              pmuir Pete Muir
              Reporter:
              pmuir Pete Muir
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development