We've got an application state object into which we're injecting some
beans from Spring. Over time we've tried a number of approaches to
this.
Under Tapestry 3, we'd cobbled this together with some code in a
pageBeginRender() listener in a base page class. The pages had access
to the Spring context more directly, so as each page started to render,
it would "manually" inject the Visit with a number of these beans from
Spring.
This smelled a bit, so under Tapestry 4 we moved to a model where we're
injecting via Hivemind. We have a StateObjectFactory which pulls what
we need out of Spring as Visits are created.
The problem is that this approach is incompatible with persistent
sessions: the beans we're injecting from Spring are all trussed up with
proxies and aspects, so they're not in the least bit serializable. It
would be lovely if the framework could handle this for us, so that we
could just use @InjectSpring right inside state objects, and the
framework would take care of re-injecting as necessary (e.g. when the
deserialized value is null).
Maybe keeping this sort of stuff out of state objects is a good idea.
It's a natural factoring, given what we're doing, but this seems to make
it inadvisable.
Anyone else had to deal with this?
Thanks,
Michael Prescott
