Details

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

      Gliffy Diagrams

        Issue Links

          Activity

          Hide
          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
          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
          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
          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
          Richard Hightower added a comment -

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

          Show
          Richard Hightower added a comment - Got it. Makes sense. Sort of like BeanNameAware in Spring.
          Hide
          Pete Muir added a comment -
          Show
          Pete Muir added a comment - https://github.com/jboss/cdi/pull/53
          Hide
          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
          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
          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
          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 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 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
          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
          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
          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
          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
          Pete Muir added a comment -

          Merged changes.

          Show
          Pete Muir added a comment - Merged changes.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development