Extensions and spec-related observer method injection points question

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Extensions and spec-related observer method injection points question

Laird Nelson
This section (http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events) says: "If other beans [other than the BeanManager] are injected into an [portable] extension’s observer methods, non-portable behavior results."

Rephrased: a portable extension's observer methods must have a minimum of one parameter (the event being observed) and a maximum of two parameters (that plus the BeanManager), and none other if you want to stay truly portable.

For true container lifecycle events, I understand this (you don't have beans to inject yet).  But given that a bean must be provided by the container for a portable extension (http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events), wouldn't it be reasonable to permit extra injection points in a portable extension's non-container-lifecycle-event-observing observer methods?

Concretely, I'd like to do this:

  // In my portable extension
  private static final void doSomethingAtStartup(@Observes @Initialized(ApplicationScoped.class) final Object event, final Frobnicator someBean) {
    someBean.doSomething();
  }

...but that would seem to be in violation of the specification.  Could someone kindly explain why?

Thanks,
Best,
Laird

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Extensions and spec-related observer method injection points question

Matej Novotny
Hi, comment inline.

----- Original Message -----

> From: "Laird Nelson" <[hidden email]>
> To: [hidden email]
> Sent: Thursday, February 16, 2017 11:11:41 PM
> Subject: [cdi-dev] Extensions and spec-related observer method injection points question
>
> This section (
> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ) says: "If
> other beans [other than the BeanManager ] are injected into an [portable]
> extension’s observer methods, non-portable behavior results."
>
> Rephrased: a portable extension's observer methods must have a minimum of one
> parameter (the event being observed) and a maximum of two parameters (that
> plus the BeanManager ), and none other if you want to stay truly portable.

That's correct interpretation.

> For true container lifecycle events, I understand this (you don't have beans
> to inject yet). But given that a bean must be provided by the container for
> a portable extension (
> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ), wouldn't
> it be reasonable to permit extra injection points in a portable extension's
> non -container-lifecycle-event-observing observer methods?
>
> Concretely, I'd like to do this:
>
> // In my portable extension
> private static final void doSomethingAtStartup(@Observes
> @Initialized(ApplicationScoped.class) final Object event, final Frobnicator
> someBean) {
> someBean.doSomething();
> }

While you cannot do this, you can still get hold of BeanManager and use it to resolve your bean.

>
> ...but that would seem to be in violation of the specification. Could someone
> kindly explain why?

Not really sure, perhaps Martin or Antoine can share the details.
But I would say this could create quite some confusion if in some observer you could inject certain beans and in others you couldn't.
Even in your sample, you can only inject AppScoped beans, so imagine you do such observer for, say, SessionScoped, what can you inject there?
SessionScoped for sure, how about Req? Conversation?

>
> Thanks,
> Best,
> Laird
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Extensions and spec-related observer method injection points question

Martin Kouba
Dne 17.2.2017 v 07:08 Matej Novotny napsal(a):

> Hi, comment inline.
>
> ----- Original Message -----
>> From: "Laird Nelson" <[hidden email]>
>> To: [hidden email]
>> Sent: Thursday, February 16, 2017 11:11:41 PM
>> Subject: [cdi-dev] Extensions and spec-related observer method injection points question
>>
>> This section (
>> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ) says: "If
>> other beans [other than the BeanManager ] are injected into an [portable]
>> extension’s observer methods, non-portable behavior results."
>>
>> Rephrased: a portable extension's observer methods must have a minimum of one
>> parameter (the event being observed) and a maximum of two parameters (that
>> plus the BeanManager ), and none other if you want to stay truly portable.
>
> That's correct interpretation.
>
>> For true container lifecycle events, I understand this (you don't have beans
>> to inject yet). But given that a bean must be provided by the container for
>> a portable extension (
>> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ), wouldn't
>> it be reasonable to permit extra injection points in a portable extension's
>> non -container-lifecycle-event-observing observer methods?
>>
>> Concretely, I'd like to do this:
>>
>> // In my portable extension
>> private static final void doSomethingAtStartup(@Observes
>> @Initialized(ApplicationScoped.class) final Object event, final Frobnicator
>> someBean) {
>> someBean.doSomething();
>> }
>
> While you cannot do this, you can still get hold of BeanManager and use it to resolve your bean.
>
>>
>> ...but that would seem to be in violation of the specification. Could someone

It's not a violation, it's a non-portable behavior. Weld should not
complain about the injection points of the doSomethingAtStartup()
observer method.

>> kindly explain why?
>
> Not really sure, perhaps Martin or Antoine can share the details.
> But I would say this could create quite some confusion if in some observer you could inject certain beans and in others you couldn't.

Yes, I think the possible confusion was the only reason.

> Even in your sample, you can only inject AppScoped beans, so imagine you do such observer for, say, SessionScoped, what can you inject there?
> SessionScoped for sure, how about Req? Conversation?
>
>>
>> Thanks,
>> Best,
>> Laird
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code
>> under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other intellectual
>> property rights inherent in such information.
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Extensions and spec-related observer method injection points question

Antoine Sabot-Durand
Administrator
Hi all,

First Laird, thanks you for all your feedback on CDI, they are very helpful.
This section is indeed not clear, but my understanding is this one:

1) As we mention the fact that BeanManager.fire() can be invoked in an extension lifecycle event observer, it makes sense to say observer on lifecycle payload are supported in extension, otherwise firing an event during the BeforeBeanDiscovery lifecycle event for instance would be useless since the only CDI elements "discovered" at this step are portable extensions

I tested in various Weld and OWB version, observers on non lifecycle payload are called when BeanManager.fire() is called 

2) If extension can contain observers with custom payload that can be invoked during container bootstrapping, it is quite understandable that adding parameters to these observer can bring issue: matching bean may not have been discovered yet and will result in an error. So for me, it makes sense to say that having an observer injecting something else than BeanManager in an extension is not safe and shouldn't be supported
 In other words

void MyObserver(@Observes MyPayload payload) { ... ) 

and 

void MyObserver(@Observes MyPayload payload, BeanManager bm) { ... )

are supported in an extension, but

void MyObserver(@Observes MyPayload payload, MyBean bean) { ... ) 

is not because MyBean may be not discovered yet when observer will be triggered.

Weld doesn't support it, while OWB does, so we face a non portable feature here ;).

3) A side effect of your mail made me also realise that we mention BeanManger.fire() in this section despite its deprecation in CDI 2.0 (we should mention BeanManager.getEvent().select().fire())

This section really needs clarification, I'll create the ticket when we agree on what is part of the spec and not ;).


Antoine


On Fri, Feb 17, 2017 at 9:16 AM Martin Kouba <[hidden email]> wrote:
Dne 17.2.2017 v 07:08 Matej Novotny napsal(a):
> Hi, comment inline.
>
> ----- Original Message -----
>> From: "Laird Nelson" <[hidden email]>
>> To: [hidden email]
>> Sent: Thursday, February 16, 2017 11:11:41 PM
>> Subject: [cdi-dev] Extensions and spec-related observer method injection     points question
>>
>> This section (
>> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ) says: "If
>> other beans [other than the BeanManager ] are injected into an [portable]
>> extension’s observer methods, non-portable behavior results."
>>
>> Rephrased: a portable extension's observer methods must have a minimum of one
>> parameter (the event being observed) and a maximum of two parameters (that
>> plus the BeanManager ), and none other if you want to stay truly portable.
>
> That's correct interpretation.
>
>> For true container lifecycle events, I understand this (you don't have beans
>> to inject yet). But given that a bean must be provided by the container for
>> a portable extension (
>> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ), wouldn't
>> it be reasonable to permit extra injection points in a portable extension's
>> non -container-lifecycle-event-observing observer methods?
>>
>> Concretely, I'd like to do this:
>>
>> // In my portable extension
>> private static final void doSomethingAtStartup(@Observes
>> @Initialized(ApplicationScoped.class) final Object event, final Frobnicator
>> someBean) {
>> someBean.doSomething();
>> }
>
> While you cannot do this, you can still get hold of BeanManager and use it to resolve your bean.
>
>>
>> ...but that would seem to be in violation of the specification. Could someone

It's not a violation, it's a non-portable behavior. Weld should not
complain about the injection points of the doSomethingAtStartup()
observer method.

>> kindly explain why?
>
> Not really sure, perhaps Martin or Antoine can share the details.
> But I would say this could create quite some confusion if in some observer you could inject certain beans and in others you couldn't.

Yes, I think the possible confusion was the only reason.

> Even in your sample, you can only inject AppScoped beans, so imagine you do such observer for, say, SessionScoped, what can you inject there?
> SessionScoped for sure, how about Req? Conversation?
>
>>
>> Thanks,
>> Best,
>> Laird
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code
>> under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other intellectual
>> property rights inherent in such information.
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Extensions and spec-related observer method injection points question

Martin Kouba
Dne 17.2.2017 v 10:19 Antoine Sabot-Durand napsal(a):

> Hi all,
>
> First Laird, thanks you for all your feedback on CDI, they are very helpful.
> This section is indeed not clear, but my understanding is this one:
>
> 1) As we mention the fact that BeanManager.fire() can be invoked in an
> extension lifecycle event observer, it makes sense to say observer on
> lifecycle payload are supported in extension, otherwise firing an event
> during the BeforeBeanDiscovery lifecycle event for instance would be
> useless since the only CDI elements "discovered" at this step are
> portable extensions
>
> I tested in various Weld and OWB version, observers on non lifecycle
> payload are called when BeanManager.fire() is called
>
> 2) If extension can contain observers with custom payload that can be
> invoked during container bootstrapping, it is quite understandable that
> adding parameters to these observer can bring issue: matching bean may
> not have been discovered yet and will result in an error.

That's a good point.

> So for me, it makes sense to say that having an observer injecting something else than
> BeanManager in an extension is not safe and shouldn't be supported
>  In other words
>
> void MyObserver(@Observes MyPayload payload) { ... )
>
> and
>
> void MyObserver(@Observes MyPayload payload, BeanManager bm) { ... )
>
> are supported in an extension, but
>
> void MyObserver(@Observes MyPayload payload, MyBean bean) { ... )
>
> is not because MyBean may be not discovered yet when observer will be
> triggered.
>
> Weld doesn't support it

Are you sure Antoine? I quicly checked the Weld 3 codebase and
"myObserver(@Observes MyPayload payload, MyBean bean)" should work. We
only check injection points for container lifecycle events...

>, while OWB does, so we face a non portable
> feature here ;).
>
> 3) A side effect of your mail made me also realise that we mention
> BeanManger.fire() in this section despite its deprecation in CDI 2.0 (we
> should mention BeanManager.getEvent().select().fire())
>
> This section really needs clarification, I'll create the ticket when we
> agree on what is part of the spec and not ;).
>
>
> Antoine
>
>
> On Fri, Feb 17, 2017 at 9:16 AM Martin Kouba <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Dne 17.2.2017 v 07:08 Matej Novotny napsal(a):
>     > Hi, comment inline.
>     >
>     > ----- Original Message -----
>     >> From: "Laird Nelson" <[hidden email] <mailto:[hidden email]>>
>     >> To: [hidden email] <mailto:[hidden email]>
>     >> Sent: Thursday, February 16, 2017 11:11:41 PM
>     >> Subject: [cdi-dev] Extensions and spec-related observer method
>     injection     points question
>     >>
>     >> This section (
>     >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events
>     ) says: "If
>     >> other beans [other than the BeanManager ] are injected into an
>     [portable]
>     >> extension’s observer methods, non-portable behavior results."
>     >>
>     >> Rephrased: a portable extension's observer methods must have a
>     minimum of one
>     >> parameter (the event being observed) and a maximum of two
>     parameters (that
>     >> plus the BeanManager ), and none other if you want to stay truly
>     portable.
>     >
>     > That's correct interpretation.
>     >
>     >> For true container lifecycle events, I understand this (you don't
>     have beans
>     >> to inject yet). But given that a bean must be provided by the
>     container for
>     >> a portable extension (
>     >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events
>     ), wouldn't
>     >> it be reasonable to permit extra injection points in a portable
>     extension's
>     >> non -container-lifecycle-event-observing observer methods?
>     >>
>     >> Concretely, I'd like to do this:
>     >>
>     >> // In my portable extension
>     >> private static final void doSomethingAtStartup(@Observes
>     >> @Initialized(ApplicationScoped.class) final Object event, final
>     Frobnicator
>     >> someBean) {
>     >> someBean.doSomething();
>     >> }
>     >
>     > While you cannot do this, you can still get hold of BeanManager
>     and use it to resolve your bean.
>     >
>     >>
>     >> ...but that would seem to be in violation of the specification.
>     Could someone
>
>     It's not a violation, it's a non-portable behavior. Weld should not
>     complain about the injection points of the doSomethingAtStartup()
>     observer method.
>
>     >> kindly explain why?
>     >
>     > Not really sure, perhaps Martin or Antoine can share the details.
>     > But I would say this could create quite some confusion if in some
>     observer you could inject certain beans and in others you couldn't.
>
>     Yes, I think the possible confusion was the only reason.
>
>     > Even in your sample, you can only inject AppScoped beans, so
>     imagine you do such observer for, say, SessionScoped, what can you
>     inject there?
>     > SessionScoped for sure, how about Req? Conversation?
>     >
>     >>
>     >> Thanks,
>     >> Best,
>     >> Laird
>     >>
>     >> _______________________________________________
>     >> cdi-dev mailing list
>     >> [hidden email] <mailto:[hidden email]>
>     >> https://lists.jboss.org/mailman/listinfo/cdi-dev
>     >>
>     >> Note that for all code provided on this list, the provider
>     licenses the code
>     >> under the Apache License, Version 2
>     >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>     ideas
>     >> provided on this list, the provider waives all patent and other
>     intellectual
>     >> property rights inherent in such information.
>     >
>     > _______________________________________________
>     > cdi-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/cdi-dev
>     >
>     > Note that for all code provided on this list, the provider
>     licenses the code under the Apache License, Version 2
>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>     ideas provided on this list, the provider waives all patent and
>     other intellectual property rights inherent in such information.
>     >
>
>     --
>     Martin Kouba
>     Senior Software Engineer
>     Red Hat, Czech Republic
>     _______________________________________________
>     cdi-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>     Note that for all code provided on this list, the provider licenses
>     the code under the Apache License, Version 2
>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>     ideas provided on this list, the provider waives all patent and
>     other intellectual property rights inherent in such information.
>

--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Extensions and spec-related observer method injection points question

Antoine Sabot-Durand
Administrator


On Fri, Feb 17, 2017 at 10:36 AM Martin Kouba <[hidden email]> wrote:
Dne 17.2.2017 v 10:19 Antoine Sabot-Durand napsal(a):
> Hi all,
>
> First Laird, thanks you for all your feedback on CDI, they are very helpful.
> This section is indeed not clear, but my understanding is this one:
>
> 1) As we mention the fact that BeanManager.fire() can be invoked in an
> extension lifecycle event observer, it makes sense to say observer on
> lifecycle payload are supported in extension, otherwise firing an event
> during the BeforeBeanDiscovery lifecycle event for instance would be
> useless since the only CDI elements "discovered" at this step are
> portable extensions
>
> I tested in various Weld and OWB version, observers on non lifecycle
> payload are called when BeanManager.fire() is called
>
> 2) If extension can contain observers with custom payload that can be
> invoked during container bootstrapping, it is quite understandable that
> adding parameters to these observer can bring issue: matching bean may
> not have been discovered yet and will result in an error.

That's a good point.

> So for me, it makes sense to say that having an observer injecting something else than
> BeanManager in an extension is not safe and shouldn't be supported
>  In other words
>
> void MyObserver(@Observes MyPayload payload) { ... )
>
> and
>
> void MyObserver(@Observes MyPayload payload, BeanManager bm) { ... )
>
> are supported in an extension, but
>
> void MyObserver(@Observes MyPayload payload, MyBean bean) { ... )
>
> is not because MyBean may be not discovered yet when observer will be
> triggered.
>
> Weld doesn't support it

Are you sure Antoine? I quicly checked the Weld 3 codebase and
"myObserver(@Observes MyPayload payload, MyBean bean)" should work. We
only check injection points for container lifecycle events...

Oops, you're right, I was a bit too fast in my writing, what is not supported in Weld (tested with 2.3.2, 2.4.2 and 3.0.0-CR1)and works in OWB is  

void MyObserver(@Observes @Initialized(ApplicationScoped.class) Object payload, MyBean bean) { ... )

Weld throws the following exception:

WELD-000409: Observer method for container lifecycle event can only inject BeanManager

Which is not very clear since the payload is not exactly a container lifecycle event... 

 
>, while OWB does, so we face a non portable
> feature here ;).
>
> 3) A side effect of your mail made me also realise that we mention
> BeanManger.fire() in this section despite its deprecation in CDI 2.0 (we
> should mention BeanManager.getEvent().select().fire())
>
> This section really needs clarification, I'll create the ticket when we
> agree on what is part of the spec and not ;).
>
>
> Antoine
>
>
> On Fri, Feb 17, 2017 at 9:16 AM Martin Kouba <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Dne 17.2.2017 v 07:08 Matej Novotny napsal(a):
>     > Hi, comment inline.
>     >
>     > ----- Original Message -----
>     >> From: "Laird Nelson" <[hidden email] <mailto:[hidden email]>>
>     >> To: [hidden email] <mailto:[hidden email]>
>     >> Sent: Thursday, February 16, 2017 11:11:41 PM
>     >> Subject: [cdi-dev] Extensions and spec-related observer method
>     injection     points question
>     >>
>     >> This section (
>     >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events
>     ) says: "If
>     >> other beans [other than the BeanManager ] are injected into an
>     [portable]
>     >> extension’s observer methods, non-portable behavior results."
>     >>
>     >> Rephrased: a portable extension's observer methods must have a
>     minimum of one
>     >> parameter (the event being observed) and a maximum of two
>     parameters (that
>     >> plus the BeanManager ), and none other if you want to stay truly
>     portable.
>     >
>     > That's correct interpretation.
>     >
>     >> For true container lifecycle events, I understand this (you don't
>     have beans
>     >> to inject yet). But given that a bean must be provided by the
>     container for
>     >> a portable extension (
>     >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events
>     ), wouldn't
>     >> it be reasonable to permit extra injection points in a portable
>     extension's
>     >> non -container-lifecycle-event-observing observer methods?
>     >>
>     >> Concretely, I'd like to do this:
>     >>
>     >> // In my portable extension
>     >> private static final void doSomethingAtStartup(@Observes
>     >> @Initialized(ApplicationScoped.class) final Object event, final
>     Frobnicator
>     >> someBean) {
>     >> someBean.doSomething();
>     >> }
>     >
>     > While you cannot do this, you can still get hold of BeanManager
>     and use it to resolve your bean.
>     >
>     >>
>     >> ...but that would seem to be in violation of the specification.
>     Could someone
>
>     It's not a violation, it's a non-portable behavior. Weld should not
>     complain about the injection points of the doSomethingAtStartup()
>     observer method.
>
>     >> kindly explain why?
>     >
>     > Not really sure, perhaps Martin or Antoine can share the details.
>     > But I would say this could create quite some confusion if in some
>     observer you could inject certain beans and in others you couldn't.
>
>     Yes, I think the possible confusion was the only reason.
>
>     > Even in your sample, you can only inject AppScoped beans, so
>     imagine you do such observer for, say, SessionScoped, what can you
>     inject there?
>     > SessionScoped for sure, how about Req? Conversation?
>     >
>     >>
>     >> Thanks,
>     >> Best,
>     >> Laird
>     >>
>     >> _______________________________________________
>     >> cdi-dev mailing list
>     >> [hidden email] <mailto:[hidden email]>
>     >> https://lists.jboss.org/mailman/listinfo/cdi-dev
>     >>
>     >> Note that for all code provided on this list, the provider
>     licenses the code
>     >> under the Apache License, Version 2
>     >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>     ideas
>     >> provided on this list, the provider waives all patent and other
>     intellectual
>     >> property rights inherent in such information.
>     >
>     > _______________________________________________
>     > cdi-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/cdi-dev
>     >
>     > Note that for all code provided on this list, the provider
>     licenses the code under the Apache License, Version 2
>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>     ideas provided on this list, the provider waives all patent and
>     other intellectual property rights inherent in such information.
>     >
>
>     --
>     Martin Kouba
>     Senior Software Engineer
>     Red Hat, Czech Republic
>     _______________________________________________
>     cdi-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>     Note that for all code provided on this list, the provider licenses
>     the code under the Apache License, Version 2
>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>     ideas provided on this list, the provider waives all patent and
>     other intellectual property rights inherent in such information.
>

--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Extensions and spec-related observer method injection points question

Antoine Sabot-Durand
Administrator
After discussing and testing with Martin we discovered that having an Observer with a payload of type Object and an injected parameter that is not BeanManager is not supported.

For instance:
void MyObserver(@Observes Object payload, MyBean bean) { ... )

Which makes sense since with observer resolution rules this observer will be invoked for all Lifecycle events.

Now, when the payload has a qualifier this makes no difference for Weld and the deployment also fails with:

void MyObserver(@Observes @Initialized(ApplicationScoped.class) Object payload, MyBean bean) { ... )

So discussion may focus on supporting this very specific use case in Weld and eventually in the spec.

Antoine


On Fri, Feb 17, 2017 at 10:52 AM Antoine Sabot-Durand <[hidden email]> wrote:
On Fri, Feb 17, 2017 at 10:36 AM Martin Kouba <[hidden email]> wrote:
Dne 17.2.2017 v 10:19 Antoine Sabot-Durand napsal(a):
> Hi all,
>
> First Laird, thanks you for all your feedback on CDI, they are very helpful.
> This section is indeed not clear, but my understanding is this one:
>
> 1) As we mention the fact that BeanManager.fire() can be invoked in an
> extension lifecycle event observer, it makes sense to say observer on
> lifecycle payload are supported in extension, otherwise firing an event
> during the BeforeBeanDiscovery lifecycle event for instance would be
> useless since the only CDI elements "discovered" at this step are
> portable extensions
>
> I tested in various Weld and OWB version, observers on non lifecycle
> payload are called when BeanManager.fire() is called
>
> 2) If extension can contain observers with custom payload that can be
> invoked during container bootstrapping, it is quite understandable that
> adding parameters to these observer can bring issue: matching bean may
> not have been discovered yet and will result in an error.

That's a good point.

> So for me, it makes sense to say that having an observer injecting something else than
> BeanManager in an extension is not safe and shouldn't be supported
>  In other words
>
> void MyObserver(@Observes MyPayload payload) { ... )
>
> and
>
> void MyObserver(@Observes MyPayload payload, BeanManager bm) { ... )
>
> are supported in an extension, but
>
> void MyObserver(@Observes MyPayload payload, MyBean bean) { ... )
>
> is not because MyBean may be not discovered yet when observer will be
> triggered.
>
> Weld doesn't support it

Are you sure Antoine? I quicly checked the Weld 3 codebase and
"myObserver(@Observes MyPayload payload, MyBean bean)" should work. We
only check injection points for container lifecycle events...

Oops, you're right, I was a bit too fast in my writing, what is not supported in Weld (tested with 2.3.2, 2.4.2 and 3.0.0-CR1)and works in OWB is  

void MyObserver(@Observes @Initialized(ApplicationScoped.class) Object payload, MyBean bean) { ... )

Weld throws the following exception:

WELD-000409: Observer method for container lifecycle event can only inject BeanManager

Which is not very clear since the payload is not exactly a container lifecycle event... 

 
>, while OWB does, so we face a non portable

> feature here ;).
>
> 3) A side effect of your mail made me also realise that we mention
> BeanManger.fire() in this section despite its deprecation in CDI 2.0 (we
> should mention BeanManager.getEvent().select().fire())
>
> This section really needs clarification, I'll create the ticket when we
> agree on what is part of the spec and not ;).
>
>
> Antoine
>
>
> On Fri, Feb 17, 2017 at 9:16 AM Martin Kouba <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Dne 17.2.2017 v 07:08 Matej Novotny napsal(a):
>     > Hi, comment inline.
>     >
>     > ----- Original Message -----
>     >> From: "Laird Nelson" <[hidden email] <mailto:[hidden email]>>
>     >> To: [hidden email] <mailto:[hidden email]>
>     >> Sent: Thursday, February 16, 2017 11:11:41 PM
>     >> Subject: [cdi-dev] Extensions and spec-related observer method
>     injection     points question
>     >>
>     >> This section (
>     >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events
>     ) says: "If
>     >> other beans [other than the BeanManager ] are injected into an
>     [portable]
>     >> extension’s observer methods, non-portable behavior results."
>     >>
>     >> Rephrased: a portable extension's observer methods must have a
>     minimum of one
>     >> parameter (the event being observed) and a maximum of two
>     parameters (that
>     >> plus the BeanManager ), and none other if you want to stay truly
>     portable.
>     >
>     > That's correct interpretation.
>     >
>     >> For true container lifecycle events, I understand this (you don't
>     have beans
>     >> to inject yet). But given that a bean must be provided by the
>     container for
>     >> a portable extension (
>     >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events
>     ), wouldn't
>     >> it be reasonable to permit extra injection points in a portable
>     extension's
>     >> non -container-lifecycle-event-observing observer methods?
>     >>
>     >> Concretely, I'd like to do this:
>     >>
>     >> // In my portable extension
>     >> private static final void doSomethingAtStartup(@Observes
>     >> @Initialized(ApplicationScoped.class) final Object event, final
>     Frobnicator
>     >> someBean) {
>     >> someBean.doSomething();
>     >> }
>     >
>     > While you cannot do this, you can still get hold of BeanManager
>     and use it to resolve your bean.
>     >
>     >>
>     >> ...but that would seem to be in violation of the specification.
>     Could someone
>
>     It's not a violation, it's a non-portable behavior. Weld should not
>     complain about the injection points of the doSomethingAtStartup()
>     observer method.
>
>     >> kindly explain why?
>     >
>     > Not really sure, perhaps Martin or Antoine can share the details.
>     > But I would say this could create quite some confusion if in some
>     observer you could inject certain beans and in others you couldn't.
>
>     Yes, I think the possible confusion was the only reason.
>
>     > Even in your sample, you can only inject AppScoped beans, so
>     imagine you do such observer for, say, SessionScoped, what can you
>     inject there?
>     > SessionScoped for sure, how about Req? Conversation?
>     >
>     >>
>     >> Thanks,
>     >> Best,
>     >> Laird
>     >>
>     >> _______________________________________________
>     >> cdi-dev mailing list
>     >> [hidden email] <mailto:[hidden email]>
>     >> https://lists.jboss.org/mailman/listinfo/cdi-dev
>     >>
>     >> Note that for all code provided on this list, the provider
>     licenses the code
>     >> under the Apache License, Version 2
>     >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>     ideas
>     >> provided on this list, the provider waives all patent and other
>     intellectual
>     >> property rights inherent in such information.
>     >
>     > _______________________________________________
>     > cdi-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/cdi-dev
>     >
>     > Note that for all code provided on this list, the provider
>     licenses the code under the Apache License, Version 2
>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>     ideas provided on this list, the provider waives all patent and
>     other intellectual property rights inherent in such information.
>     >
>
>     --
>     Martin Kouba
>     Senior Software Engineer
>     Red Hat, Czech Republic
>     _______________________________________________
>     cdi-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>     Note that for all code provided on this list, the provider licenses
>     the code under the Apache License, Version 2
>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>     ideas provided on this list, the provider waives all patent and
>     other intellectual property rights inherent in such information.
>

--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Extensions and spec-related observer method injection points question

Laird Nelson
On Fri, Feb 17, 2017 at 3:37 AM Antoine Sabot-Durand <[hidden email]> wrote:
After discussing and testing with Martin we discovered that having an Observer with a payload of type Object and an injected parameter that is not BeanManager is not supported.

For instance:
void MyObserver(@Observes Object payload, MyBean bean) { ... )

Which makes sense since with observer resolution rules this observer will be invoked for all Lifecycle events.

Oh, that very specific aspect is an aspect I hadn't considered.  That makes sense.

Your earlier point about how MyBean might not be resolved at invocation time was one I didn't understand.  If I have:

void MyObserver(@Observes @Initialized(ApplicationScoped.class) Object payload, MyBean bean) { ... }

...then surely MyBean would be resolved at this point, by definition?  (I understand you're looking at this specific case, but even more generally here: wouldn't MyBean be guaranteed to be resolved here?)

Best,
Laird

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Extensions and spec-related observer method injection points question

Laird Nelson
In reply to this post by Matej Novotny
On Thu, Feb 16, 2017 at 10:08 PM Matej Novotny <[hidden email]> wrote:
> Concretely, I'd like to do this:
>
> // In my portable extension
> private static final void doSomethingAtStartup(@Observes
> @Initialized(ApplicationScoped.class) final Object event, final Frobnicator
> someBean) {
> someBean.doSomething();
> }

While you cannot do this, you can still get hold of BeanManager and use it to resolve your bean.

Right; that's what I'm doing at the moment.
 
But I would say this could create quite some confusion if in some observer you could inject certain beans and in others you couldn't.

Sure.
 
Even in your sample, you can only inject AppScoped beans, so imagine you do such observer for, say, SessionScoped, what can you inject there?
SessionScoped for sure, how about Req? Conversation?

First, thanks to Martin, Antoine, yourself, etc. for looking at this.  The issue is not holding me up, and I can make headway, etc.  My remarks here are just because I'm curious.  :-)

Forgetting about confusion, couldn't I inject any bean I want in a non-container-lifecycle-event-observing observer method in my extension?  I understand it's not supported right now, and I also understand Antoine's excellent point that observing a payload of type Object would, in a portable extension, be too "broad".  Let's forget about that for a moment, and pretend that it's not an issue, and just focus on resolution issues.

Surely this:

void MyObserver(@Observes Object payload, SomeBean bean) { ... }

...would work (again, forgetting about the fact that due to resolution rules this would also be called for lifecycle events; I'm interested purely in resolution issues of that SomeBean parameter)?  

My point is, a portable extension "becomes" a bean (in application scope, according to the specification), and so therefore is eligible to use other beans, no matter what scope they're in, some of whose Contexts might be active, and some of whose might not be active.  Obviously trying to use a bean before the container has gotten through AfterDeploymentValidation won't work, but after that point...?

Like I said, now I'm just curious.  :-)

Best,
Laird

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Extensions and spec-related observer method injection points question

Antoine Sabot-Durand
Administrator
Check https://issues.jboss.org/browse/WELD-2338

Regarding Extension being beans, it's the case, but rather special beans since you can't perform field, constructor or initializer injection in them.
For observer that might be called during bootstrap (observing Object for instance) they will throw exception if they inject parameters as well since their matching beans are not resolvable yet.
A good practice could be: use observers with personal payload without parameter injection and only for specific operation during bootstrap (Romain wrote an interesting post on the topic: https://blog-rmannibucau.rhcloud.com/#/post/share-data-in-cdi-extensions)
Create a specific bean to declare your observers and inject the extension and other beans as parameter.

If you really want to have your observers in your extension, inject BeanManager and perform the resolution with it...

Antoine 




On Fri, Feb 17, 2017 at 5:56 PM Laird Nelson <[hidden email]> wrote:
On Thu, Feb 16, 2017 at 10:08 PM Matej Novotny <[hidden email]> wrote:
> Concretely, I'd like to do this:
>
> // In my portable extension
> private static final void doSomethingAtStartup(@Observes
> @Initialized(ApplicationScoped.class) final Object event, final Frobnicator
> someBean) {
> someBean.doSomething();
> }

While you cannot do this, you can still get hold of BeanManager and use it to resolve your bean.

Right; that's what I'm doing at the moment.
 
But I would say this could create quite some confusion if in some observer you could inject certain beans and in others you couldn't.

Sure.
 
Even in your sample, you can only inject AppScoped beans, so imagine you do such observer for, say, SessionScoped, what can you inject there?
SessionScoped for sure, how about Req? Conversation?

First, thanks to Martin, Antoine, yourself, etc. for looking at this.  The issue is not holding me up, and I can make headway, etc.  My remarks here are just because I'm curious.  :-)

Forgetting about confusion, couldn't I inject any bean I want in a non-container-lifecycle-event-observing observer method in my extension?  I understand it's not supported right now, and I also understand Antoine's excellent point that observing a payload of type Object would, in a portable extension, be too "broad".  Let's forget about that for a moment, and pretend that it's not an issue, and just focus on resolution issues.

Surely this:

void MyObserver(@Observes Object payload, SomeBean bean) { ... }

...would work (again, forgetting about the fact that due to resolution rules this would also be called for lifecycle events; I'm interested purely in resolution issues of that SomeBean parameter)?  

My point is, a portable extension "becomes" a bean (in application scope, according to the specification), and so therefore is eligible to use other beans, no matter what scope they're in, some of whose Contexts might be active, and some of whose might not be active.  Obviously trying to use a bean before the container has gotten through AfterDeploymentValidation won't work, but after that point...?

Like I said, now I'm just curious.  :-)

Best,
Laird
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Extensions and spec-related observer method injection points question

Laird Nelson
On Fri, Feb 17, 2017 at 9:30 AM Antoine Sabot-Durand <[hidden email]> wrote:
Regarding Extension being beans, it's the case, but rather special beans since you can't perform field, constructor or initializer injection in them.

Sure; obviously there are issues with exactly when a portable extension "becomes" a bean.  You don't want to use "bean-like" features while the container is still coming up.
 
For observer that might be called during bootstrap (observing Object for instance) they will throw exception if they inject parameters as well since their matching beans are not resolvable yet.

Right; this was an excellent point you made earlier—specifically the part about observing Object; the related point that other observer method parameters might not be resolved seemed irrelevant to me, since by definition a non-container-lifecycle-event-observing observer method would not be invoked until deployment validation was complete—and which I had not thought about.
 
A good practice could be: use observers with personal payload without parameter injection and only for specific operation during bootstrap (Romain wrote an interesting post on the topic: https://blog-rmannibucau.rhcloud.com/#/post/share-data-in-cdi-extensions)
Create a specific bean to declare your observers and inject the extension and other beans as parameter.

Yes; I am heading this way.  I had some shared state across lifecycle event observers and "regular" observers and was hoping to keep that isolated to a private instance variable but I can refactor this.
 
If you really want to have your observers in your extension, inject BeanManager and perform the resolution with it...
 
That's what I'm doing now but it doesn't "read" as nicely; that's fine.

Best,
Laird

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Extensions and spec-related observer method injection points question

Mark Struberg
In reply to this post by Martin Kouba
What you can portably do is to fire an event in one CDI Extension and observe it in another Extension. Note: not a normal bean, as they are not yet started, but Extension is fine.
There is even a TCK test for it.

LieGrue,
strub


> Am 17.02.2017 um 10:36 schrieb Martin Kouba <[hidden email]>:
>
> Dne 17.2.2017 v 10:19 Antoine Sabot-Durand napsal(a):
>> Hi all,
>>
>> First Laird, thanks you for all your feedback on CDI, they are very helpful.
>> This section is indeed not clear, but my understanding is this one:
>>
>> 1) As we mention the fact that BeanManager.fire() can be invoked in an
>> extension lifecycle event observer, it makes sense to say observer on
>> lifecycle payload are supported in extension, otherwise firing an event
>> during the BeforeBeanDiscovery lifecycle event for instance would be
>> useless since the only CDI elements "discovered" at this step are
>> portable extensions
>>
>> I tested in various Weld and OWB version, observers on non lifecycle
>> payload are called when BeanManager.fire() is called
>>
>> 2) If extension can contain observers with custom payload that can be
>> invoked during container bootstrapping, it is quite understandable that
>> adding parameters to these observer can bring issue: matching bean may
>> not have been discovered yet and will result in an error.
>
> That's a good point.
>
>> So for me, it makes sense to say that having an observer injecting something else than
>> BeanManager in an extension is not safe and shouldn't be supported
>> In other words
>>
>> void MyObserver(@Observes MyPayload payload) { ... )
>>
>> and
>>
>> void MyObserver(@Observes MyPayload payload, BeanManager bm) { ... )
>>
>> are supported in an extension, but
>>
>> void MyObserver(@Observes MyPayload payload, MyBean bean) { ... )
>>
>> is not because MyBean may be not discovered yet when observer will be
>> triggered.
>>
>> Weld doesn't support it
>
> Are you sure Antoine? I quicly checked the Weld 3 codebase and
> "myObserver(@Observes MyPayload payload, MyBean bean)" should work. We
> only check injection points for container lifecycle events...
>
>> , while OWB does, so we face a non portable
>> feature here ;).
>>
>> 3) A side effect of your mail made me also realise that we mention
>> BeanManger.fire() in this section despite its deprecation in CDI 2.0 (we
>> should mention BeanManager.getEvent().select().fire())
>>
>> This section really needs clarification, I'll create the ticket when we
>> agree on what is part of the spec and not ;).
>>
>>
>> Antoine
>>
>>
>> On Fri, Feb 17, 2017 at 9:16 AM Martin Kouba <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>    Dne 17.2.2017 v 07:08 Matej Novotny napsal(a):
>>> Hi, comment inline.
>>>
>>> ----- Original Message -----
>>>> From: "Laird Nelson" <[hidden email] <mailto:[hidden email]>>
>>>> To: [hidden email] <mailto:[hidden email]>
>>>> Sent: Thursday, February 16, 2017 11:11:41 PM
>>>> Subject: [cdi-dev] Extensions and spec-related observer method
>>    injection     points question
>>>>
>>>> This section (
>>>> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events
>>    ) says: "If
>>>> other beans [other than the BeanManager ] are injected into an
>>    [portable]
>>>> extension’s observer methods, non-portable behavior results."
>>>>
>>>> Rephrased: a portable extension's observer methods must have a
>>    minimum of one
>>>> parameter (the event being observed) and a maximum of two
>>    parameters (that
>>>> plus the BeanManager ), and none other if you want to stay truly
>>    portable.
>>>
>>> That's correct interpretation.
>>>
>>>> For true container lifecycle events, I understand this (you don't
>>    have beans
>>>> to inject yet). But given that a bean must be provided by the
>>    container for
>>>> a portable extension (
>>>> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events
>>    ), wouldn't
>>>> it be reasonable to permit extra injection points in a portable
>>    extension's
>>>> non -container-lifecycle-event-observing observer methods?
>>>>
>>>> Concretely, I'd like to do this:
>>>>
>>>> // In my portable extension
>>>> private static final void doSomethingAtStartup(@Observes
>>>> @Initialized(ApplicationScoped.class) final Object event, final
>>    Frobnicator
>>>> someBean) {
>>>> someBean.doSomething();
>>>> }
>>>
>>> While you cannot do this, you can still get hold of BeanManager
>>    and use it to resolve your bean.
>>>
>>>>
>>>> ...but that would seem to be in violation of the specification.
>>    Could someone
>>
>>    It's not a violation, it's a non-portable behavior. Weld should not
>>    complain about the injection points of the doSomethingAtStartup()
>>    observer method.
>>
>>>> kindly explain why?
>>>
>>> Not really sure, perhaps Martin or Antoine can share the details.
>>> But I would say this could create quite some confusion if in some
>>    observer you could inject certain beans and in others you couldn't.
>>
>>    Yes, I think the possible confusion was the only reason.
>>
>>> Even in your sample, you can only inject AppScoped beans, so
>>    imagine you do such observer for, say, SessionScoped, what can you
>>    inject there?
>>> SessionScoped for sure, how about Req? Conversation?
>>>
>>>>
>>>> Thanks,
>>>> Best,
>>>> Laird
>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> [hidden email] <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider
>>    licenses the code
>>>> under the Apache License, Version 2
>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>    ideas
>>>> provided on this list, the provider waives all patent and other
>>    intellectual
>>>> property rights inherent in such information.
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider
>>    licenses the code under the Apache License, Version 2
>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>    ideas provided on this list, the provider waives all patent and
>>    other intellectual property rights inherent in such information.
>>>
>>
>>    --
>>    Martin Kouba
>>    Senior Software Engineer
>>    Red Hat, Czech Republic
>>    _______________________________________________
>>    cdi-dev mailing list
>>    [hidden email] <mailto:[hidden email]>
>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>    Note that for all code provided on this list, the provider licenses
>>    the code under the Apache License, Version 2
>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>    ideas provided on this list, the provider waives all patent and
>>    other intellectual property rights inherent in such information.
>>
>
> --
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Extensions and spec-related observer method injection points question

Matej Novotny
In reply to this post by Matej Novotny


----- Original Message -----

> From: "Mark Struberg" <[hidden email]>
> To: "Matej Novotny" <[hidden email]>
> Sent: Sunday, February 19, 2017 9:05:30 PM
> Subject: Re: [cdi-dev] Extensions and spec-related observer method injection points question
>
> >
> > While you cannot do this, you can still get hold of BeanManager and use it
> > to resolve your bean.
>
> No, you cannot. At least not before AfterBeanValidation.

Obviously, but the question assumes the container is in the state where beans are resolvable.
E.g., the question was meant more like "if I can resolve it with BM, why can't I use plain param. injection".

>
> LieGrue,
> strub
>
>
> > Am 17.02.2017 um 07:08 schrieb Matej Novotny <[hidden email]>:
> >
> > Hi, comment inline.
> >
> > ----- Original Message -----
> >> From: "Laird Nelson" <[hidden email]>
> >> To: [hidden email]
> >> Sent: Thursday, February 16, 2017 11:11:41 PM
> >> Subject: [cdi-dev] Extensions and spec-related observer method injection
> >> points question
> >>
> >> This section (
> >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ) says:
> >> "If
> >> other beans [other than the BeanManager ] are injected into an [portable]
> >> extension’s observer methods, non-portable behavior results."
> >>
> >> Rephrased: a portable extension's observer methods must have a minimum of
> >> one
> >> parameter (the event being observed) and a maximum of two parameters (that
> >> plus the BeanManager ), and none other if you want to stay truly portable.
> >
> > That's correct interpretation.
> >
> >> For true container lifecycle events, I understand this (you don't have
> >> beans
> >> to inject yet). But given that a bean must be provided by the container
> >> for
> >> a portable extension (
> >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ),
> >> wouldn't
> >> it be reasonable to permit extra injection points in a portable
> >> extension's
> >> non -container-lifecycle-event-observing observer methods?
> >>
> >> Concretely, I'd like to do this:
> >>
> >> // In my portable extension
> >> private static final void doSomethingAtStartup(@Observes
> >> @Initialized(ApplicationScoped.class) final Object event, final
> >> Frobnicator
> >> someBean) {
> >> someBean.doSomething();
> >> }
> >
> > While you cannot do this, you can still get hold of BeanManager and use it
> > to resolve your bean.
> >
> >>
> >> ...but that would seem to be in violation of the specification. Could
> >> someone
> >> kindly explain why?
> >
> > Not really sure, perhaps Martin or Antoine can share the details.
> > But I would say this could create quite some confusion if in some observer
> > you could inject certain beans and in others you couldn't.
> > Even in your sample, you can only inject AppScoped beans, so imagine you do
> > such observer for, say, SessionScoped, what can you inject there?
> > SessionScoped for sure, how about Req? Conversation?
> >
> >>
> >> Thanks,
> >> Best,
> >> Laird
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >> Note that for all code provided on this list, the provider licenses the
> >> code
> >> under the Apache License, Version 2
> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> >> provided on this list, the provider waives all patent and other
> >> intellectual
> >> property rights inherent in such information.
> >
> > _______________________________________________
> > cdi-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> > code under the Apache License, Version 2
> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > provided on this list, the provider waives all patent and other
> > intellectual property rights inherent in such information.
>
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.