Details

    • Type: Feature Request Feature Request
    • Status: Resolved 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 

      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: