P.s.
The BV spec ran into the same issue, see
https://hibernate.atlassian.net/browse/HV-787
They too came to the conclusion that the PassivationCapable interface
needed to be added, and in their fixing changeset they did just that:
https://github.com/hibernate/hibernate-validator/pull/236/files#r3734635
The Javadoc of PassivationCapable is a little light on the details though.
Is it a declaration that the produced artifact can be serialized, or that
the "producer" (the spi.Bean) itself can be serialised?
Kind regards,
Arjan Tijms
On Sunday, April 5, 2015, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi
>
> On Sunday, April 5, 2015, Mark Struberg <struberg_at_yahoo.de
> <javascript:_e(%7B%7D,'cvml','struberg_at_yahoo.de');>> wrote:
>
>> > Indeed, I discussed this before with Manfred. It's technically as
>> simple as letting the producer implement that interface. After that it
>> works. Since the producer is request scoped CDI will create a proxy that
>> always delegates to the right instance.
>>
>> I think a whole lot of things get mixed up here.
>
>
> Just to be sure, the "producer" in question is a
> javax.enterprise.inject.spi.Bean, see
> https://github.com/javaeekickoff/mojarra/blob/1e0ae07af899a0e1491a70fecad179b4b70b55e7/jsf-ri/src/main/java/com/sun/faces/cdi/FacesContextProducer.java
>
> If this does not implement javax.enterprise.inject.spi.PassivationCapable (
> http://docs.oracle.com/javaee/7/api/javax/enterprise/inject/spi/PassivationCapable.html)
> then the injection in session scoped beans fails.
>
> If it does inplement said interface it works.
>
> I have to retest, but if I remember correctly I tested this earlier on
> Weld, OWB and CanDI.
>
>
>
>>
>> a.) The interface doesn’t matter at all. The only thing which counts is
>> that the return type must not be a final non-serilizable class.
>> b.) For producer methods creating any NormalScoped bean (e.g.
>> @RequestScoped) you will ALWAYS get a Serializable proxy. No matter if the
>> contextual instance is serializable or not.
>> c.) For producer methods creating a @Dependent scoped bean it depends on
>> the actual returned instance. If the instance returned at runtime is
>> serializable then all is fine.
>>
>> All other behaviour is simply a bug in the implementation you did use.
>
>
> Since the interface that javax.enterprise.inject.spi.Bean implements
> seems to matter (taking into account I do have to retest to be 100% sure),
> does that possibly mean all CDI implementations are buggy here?
>
> Kind regards,
> Arjan Tijms
>
>
>
>>
>> LieGrue,
>> strub
>>
>>
>> > Am 04.04.2015 um 20:40 schrieb arjan tijms <arjan.tijms_at_gmail.com>:
>> >
>> > Hi,
>> >
>> > On Saturday, April 4, 2015, Josh Juneau <juneau001_at_gmail.com> wrote:
>> > I am developing an example application to demonstrate the features of
>> JSF 2.3. I've encountered what I would call an issue, a while back, as I
>> was unable to inject any of the Faces CDI resources into @SessionScoped
>> beans, unless I mark the injected resource(s) as transient. I have no
>> problems injecting them into @Dependent or @RequestScoped beans, of
>> course. This is obviously occurring because the producers are not
>> passivation capable.
>> >
>> > Indeed, I discussed this before with Manfred. It's technically as
>> simple as letting the producer implement that interface. After that it
>> works. Since the producer is request scoped CDI will create a proxy that
>> always delegates to the right instance.
>> >
>> > I do have to read up on what the exact consequences are of this
>> interface. Last time I looked at it I didn't found it to be overly clear.
>> >
>> > The faces context for instance is itself of course not passivisation
>> capable (serializable), but its producer is. After deserialisation CDI
>> should just create a new proxy and per request reproduce the instance.
>> >
>> >
>> >
>> > In my opinion, there are some cases where it makes sense to utilize a
>> @SessionScoped bean that contains injected resources...perhaps
>> @FacesContext, for issuing a FacesMessage. While we can certainly utilize
>> @RequestScoped beans that utilize @SessionScoped beans for management of
>> objects that need to stay within the session, that may be cumbersome under
>> some circumstances, and I can see the use case of allowing injection of
>> resources into @SessionScoped beans.
>> >
>> > They should be injectable in session scoped beans. From my part there
>> is no doubt there ;)
>> >
>> > Thanks for mentioning it!
>> >
>> > Kind regards,
>> > Arjan Tijms
>> >
>> >
>> >
>> > I wanted to bring this to the expert group to see if anyone else in the
>> group believes that we should allow injectable resources into
>> @SessionScoped beans, as I think it may promote ease of use in some
>> situations.
>> >
>> > Thanks for your time, it is appreciated.
>> >
>> > Josh Juneau
>> > juneau001_at_gmail.com
>> > http://jj-blogger.blogspot.com
>> > https://www.apress.com/index.php/author/author/view/id/1866
>> >
>>
>>