[weld-dev] PassivationCapable question

[Mark Struberg]

ping.

What is the current status? Did we already get an answer about who should be responsible, the container or the Context?

txs in advance,
strub

--- Mark Struberg <struberg at yahoo.de> schrieb am Fr, 5.2.2010:

> Von: Mark Struberg <struberg at yahoo.de>
> Betreff: Re: [weld-dev] PassivationCapable question
> An: "Pete Muir" <pmuir at redhat.com>, weld-dev at lists.jboss.org
> Datum: Freitag, 5. Februar 2010, 11:44
> 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 
> 
> _______________________________________________
> 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