Injecting State Objects w/ Non-Serializable Beans

[Michael Prescott <mp...@exchangesolutions.com>]

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

Re: Injecting State Objects w/ Non-Serializable Beans

[Ryan Holmes <ry...@hyperstep.com>]

Ideally, your state objects should be as simple and small as possible  
-- if for no other reason than to make sure your app can cluster if  
required. Also, if you're using a service then you're probably  
performing business logic and a state object is probably not the best  
place for this. I'm talking about session-scoped ASO's here and not  
global ASO's. I could see injected services making more sense in a  
global ASO but it still seems like the wrong architecture.

In any event, to get this functionality in a clean way Tapestry/ 
HiveMind would have to support re-injection on deserialization as you  
mention, and I don't think that is or very likely will be supported  
(not to discourage you from looking -- I could certainly be wrong).

I'm not sure if you're also asking about general Tapestry/Spring  
integration, but I recently switched from a custom solution based on  
the info at http://wiki.apache.org/tapestry/Tapestry4Spring to  
Howard's tapestry-spring plugin (http://howardlewisship.com/tapestry- 
javaforge/tapestry-spring/). I literally just ripped out my old  
stuff, dropped in the tapestry-spring jar and was up and running. I  
don't think the plugin is any "better" than the solution on the wiki,  
but having only 1 jar vs a few classes and HiveMind wiring is nice.

If you can outline why you need to inject services into your state  
objects in the first place, maybe I can offer an alternate solution.  
The (rather large) application my team is working on at the moment  
uses Spring beans extensively in Tapestry pages and components and  
I've never had the need or desire to inject them into state objects.  
Not to say that there couldn't be a legitimate reason to do it, I  
just haven't run into it yet.

-Ryan


On Aug 14, 2006, at 1:42 PM, Michael Prescott wrote:

> 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

Ryan Holmes, CISSP

ryan@hyperstep.com
ph. (213) 626-0026



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org