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

Von: Mark Struberg <struberg(a)yahoo.de&gt; Betreff: Re: [weld-dev] PassivationCapable question An: "Pete Muir" <pmuir(a)redhat.com&gt;, weld-dev(a)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(a)redhat.com&gt; schrieb am Mi, 3.2.2010: > Von: Pete Muir <pmuir(a)redhat.com&gt; > Betreff: Re: [weld-dev] PassivationCapable question > An: "Mark Struberg" <struberg(a)yahoo.de&gt; > 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 _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev