On 9/25/06, Ingo Düppe <[EMAIL PROTECTED]> wrote:
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.
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.
Craig
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
