myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: managed-beans, spring references, and serializable
Date Mon, 25 Sep 2006 20:42:07 GMT
On 9/25/06, Ingo Düppe <mailing-lists@dueppe.com> wrote:
>
> Craig McClanahan schrieb:
> >
> >     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
> >
> Well as I understood the spring 2.0 reference it should be possible to
> inject a request scoped bean into a session scoped bean, so spring must
> call back, so you get each time a fresh request-scoped bean. But I'm not
> really sure about this.



In standard JSF managed beans, this is explicitly disallowed.  You cannot
inject a bean with a "shorter" lifetime into a bean with a "longer"
lifetime.  The reason should be pretty obvious -- what's going to happen
when you have two simultaneous requests on the same session (*very* likely
in an AJAXish world, but not uncommon even without that).  The answer is
that the second injection would wipe out the first one, and you'd have
corrupted data.

Back to my application design.
>
> I'm using AndroMDA to generate my business and data access layer; the
> presentation layer I'm still writing manually.
>
> My controller beans (jsf backing beans) are thin beans just to trigger
> my service beans (spring beans) from the business layer.
> So a typical structure of my objects looks like this:
> RegistrationController ------> RegistrationService -------> UserDao
> -------> HibernateDaoSupport
>
> Sometimes I need to save some data like "Did the user accept the user
> agreement during the registration process". I added this temporal values
> to my RegistrationController, because it is his decision whether all
> needed data is collected to trigger the business layer or not. But this
> results in that my controller is in the session scope.
>
> So as I mentioned before, maybe I am wrong here. Maybe it is really
> smarter to separate the controller objects from state data and put them
> into application or request scope.
>
> What do you thing about this?


I would tend to maintain the temporary state information in a separate model
bean of some sort, explicitly designed to be Serializable, so that there
would not be anything special about migrating from one server instance to
another.

Regards
> Ingo


Craig

Mime
View raw message