[weld-dev] PassivationCapable question

[Pete Muir]

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