I finally had the time to try this out. The re-injection after
de-serialization apparently works now. However, the problems didn't stop
there, as I was accessing DAOs and an EntityManager from within this bean. I
read more stuff on that ( the book "Java Persistence with Hibernate" covers
this pattern quite well), and came to the conclusion that all the trouble
involved is not worth it in this particular case.
Just to put some more detail to this:
I developed this particular bean as a stateful EJB on Jboss. But as
development on Jboss is often very slow when you have to restart your server
(at least compared to Jetty), I switched to Spring. This solved some (not
all!) of the problems I had there, but raised the ones I discussed in this
thread.
At least with the current state, I would discourage anyone implementing long
conversations within spring beans. Some of the magic happening in EJB (like
propagating the "right" EntityManager to your stateful DAOs) is just not
there yet; or at least I don't see it :) The following thread was not very
encouraging either:
http://forum.springframework.org/showthread.php?t=39523&highlight=long+conversation
Still, thanks a lot again, Igor. In some other context, this might very well
become useful.
Rüdiger
2007/6/13, Rüdiger Schulz <[EMAIL PROTECTED]>:
Igor, that makes perfect sense, thank you very much. I still have to try
it, but if it works with @Configurable, this will be great! It is definitely
better than implementing readResolve(), and manually "injecting" the
dependencies via reflection, as someone suggested on the myfaces list.
I'll post my experience after trying it.
Rüdiger
2007/6/12, Igor Vaynberg <[EMAIL PROTECTED]>:
>
> if you think about it, your problem comes from the fact that you do not
> want to serialize this stateful bean because it has references to other
> beans which are not serializable and yet you want to put it into
> httpsession.
>
> the requirement of anything you put into httpsession is that it _is_
> serializable for replication to other server nodes, etc. - unless you use
> some nonstandard replication technique.
>
> shale will run into the same limitation. its "dialog" scope is pretty
> much the same as making something a field of a page. that field is there
> while the page is, and is then cleaned up when the page is not needed.
> however it runs into the same limitation because it most likely uses
> httpsession for storing that dialog-scoped data and thus you are back to
> serialization problem.
>
> now a solution i see is thus. make this bean @Configurable and
> serializable. keep all dependencies in transient vars. that way when the
> bean is serialized its dependencies are not, and when it is deserialized i
> think @Configurable wires in an intercept that will reinject the bean. that
> way you get the best of both worlds. makes sense?
>
> -igor
>
> On 6/12/07, Rüdiger Schulz < [EMAIL PROTECTED]> wrote:
> >
> > 1) Convert the bean to a stateless service, and keep the state in
> > another bean.
> > 2) Make the bean references transient, and re-fetch them manually (i.e.
> > without DI from spring) after de-serialization.
> >
> > There is nothing wrong with 1), I use it in other parts of my app. It
> > sure would be nice to have stateful beans with DI-ed application logic, but
> > 2) seems very clumsy. However, later in the above thread, someone mentions
> > the dialog feature of Shale:
> > http://mail-archives.apache.org/mod_mbox/myfaces-users/200609.mbox/[EMAIL
PROTECTED]
> >
> >
> > Maybe something like that could be applied to wicket as well?
> >
> >
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>
--
greetings from Berlin,
Rüdiger Schulz
www.2rue.de
--
greetings from Berlin,
Rüdiger Schulz
www.2rue.de
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
