On 9/25/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
And, that being said, tell me again why your Spring-created beans cannot be Serializable? That seems to be an architectural design flaw for an application that needs to be supported by a multi-server-instance application server, where the session might get migrated back and forth.
On 9/25/06, Ingo Düppe < [EMAIL PROTECTED]> wrote:Craig McClanahan schrieb:
> Shale supports a similar pattern if your session-scoped beans extend
> AbstractSessionBean. The passivate() method will be called when the
> bean is about to be swapped out (perhaps to be transferred to another
> server) so you can release references to resources that cannot be
> serialized. Later, the activate() method is called once the bean is
> re-created. This is where you would go look up the appropriate Spring
> beans again, and recreate them.
Well thanks for the hint, I will take a look how shale is solving this.
>
> JSF does implement the Hollywood Principle ("don't call us, we'll call
> you"), but it does so only once :-).
Yes your are damn right, and this hearts all the time :-( Hopefully in
Spring 2.0 the scoped beans will solve this issue (as far I understood it).
Actually, I'd be surprised (and impressed) if Spring 2.0 did something different. The basic philosophy of all the IoC frameworks I've looked at is that they only need to do their magic once, when the bean is initially created. Whatever happens after that is the responsibility of the application.
And, that being said, tell me again why your Spring-created beans cannot be Serializable? That seems to be an architectural design flaw for an application that needs to be supported by a multi-server-instance application server, where the session might get migrated back and forth.
Regards,
Ingo
Craig
Craig
