4:44 a.m.
Hi!
The whole thing this is about is the question about who is responsible for the
serialization of the Contextual<T> and CreationalContext<T> in custom context
implementations.
E.g. for a JSF @ViewScoped implementation, we have to store a Map from Contextual<T>
to ist's actual contextual instance in the JSF ViewMap - which gets serialized and
stored in the view.
There are 2 possible ways to achieve this:
1. Option) The Context implementation for the scope (JsfViewScopedContext) knows itselfs
that it should store the Contextual<T> only in a serialized form and simply calls
PassivationCapable.getId() and BeanManager.getPassivationCapableBean(id)
This is the most easy and always working way and most problably also the best from a
performance and memory footprint aspect! But on the downside it may cause unnecessary
serializations (Although getPCBean(id) is really cheap) if the e.g. session does not get
serialized often (or almost never).
2. Option) The container always passes serializable Contextual<T> and
CreationalContext<T> to the Context implementation if a contextual instance for a
NormalScoped(passivating=true) context has to be stored in a serializable form.
Please note that it's not defined in the spec whether the container is responsible for
making the Contextual<T> (== our Beans) serializable, or if the Context
implementation is. In fact, if it is 2. (as implemented in Weld currently) then you'd
need to add this to the spec explicitly!
Btw, CreationalContext<T> has currently to be Serializable in any case, because
there is no getId stuff for it but it also has to be stored along with the Contextual.
LieGrue,
strub
--- Pete Muir <pmuir(a)redhat.com> schrieb am Mi, 3.2.2010:
Von: Pete Muir <pmuir(a)redhat.com>
Betreff: Re: [weld-dev] PassivationCapable question
An: "Mark Struberg" <struberg(a)yahoo.de>
CC: weld-dev(a)lists.jboss.org
Datum: Mittwoch, 3. Februar 2010, 15:05
Hi Mark
As you can't dynamically implement interfaces at runtime,
all Beans implement PassivationCapable. Of course, this
doesn't actually indicate whether the Bean instance is
passivation capable, this is determined by the spec rules.
We could easily have written it without implementing
PassivationCapable, it would just have required an
additional check for RIBean when we generate the ID for the
bean. Also, I don't really see how this stuff is "internal
only" - Weld can correctly associate a custom Bean object
which implements PassivationCapable with it's instance
through passivation/activation.
Does that make sense?
On 3 Feb 2010, at 12:44, Mark Struberg wrote:
> Hi!
>
> Section 6.6 states that
>> A bean is called passivation capable if the
container is able to temporarily
>> transfer the state of any idle instance to
secondary storage.
>
> To me it is still not always clear if the term bean is
now solely meant as terminus technicus for Bean<T> or
if it's still sometimes used for it's contextual intances.
> For the sentence above: does 'bean ... any idle
instance' mean that it's in question whether the
Bean<T> is serializable or it's contextual instances
shall be?
>
> As far as I've seen in the RI sources, the interface
PassivationCapable has nothing to do with your 'passivation
capable' criteria used throughout 6.6 since RIBean
implements PassivationCapable indicates that all your
internal beans are passivation capable. Instead you have
internal functions to handle that. But how do portable
extensions (like a custom context implementation) access
this information?
>
> txs 4 clarifying,
> strub
>
> __________________________________________________
> Do You Yahoo!?
> Sie sind Spam leid? Yahoo! Mail verfügt über einen
herausragenden Schutz gegen Massenmails.
> http://mail.yahoo.com
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen
Massenmails.
http://mail.yahoo.com