Re: [weld-dev] PassivationCapable question
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