[cdi-dev] Fwd: Extensions and spec-related observer method injection points question

Mark Struberg struberg at yahoo.de
Sun Feb 19 15:06:32 EST 2017


Sorry, should go to reply-all.

LieGrue,
strub

> Anfang der weitergeleiteten Nachricht:
> 
> Von: Mark Struberg <struberg at yahoo.de>
> Betreff: Aw: [cdi-dev] Extensions and spec-related observer method injection points question
> Datum: 19. Februar 2017 um 21:05:30 MEZ
> An: Matej Novotny <manovotn at redhat.com>
> 
>> 
>> 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.
> 
> LieGrue,
> strub
> 
> 
>> Am 17.02.2017 um 07:08 schrieb Matej Novotny <manovotn at redhat.com>:
>> 
>> Hi, comment inline.
>> 
>> ----- Original Message -----
>>> From: "Laird Nelson" <ljnelson at gmail.com>
>>> To: cdi-dev at lists.jboss.org
>>> 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
>>> cdi-dev at lists.jboss.org
>>> 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
>> cdi-dev at lists.jboss.org
>> 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.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170219/378d97e2/attachment.html 


More information about the cdi-dev mailing list