[weld-dev] PassivationCapable question

[Mark Struberg]

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 at redhat.com> schrieb am Mi, 3.2.2010:

> Von: Pete Muir <pmuir at redhat.com>
> Betreff: Re: [weld-dev] PassivationCapable question
> An: "Mark Struberg" <struberg at yahoo.de>
> CC: weld-dev at 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 at 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