In the end I settled on a singleton wrapper for the session-scoped bean.
Not as clean as I'd have liked, but it does the trick and my time budget's
run out. :-)
Yes, I wasn't sure if Spring or Tapestry-Spring was doing the weird thing
there, but it would be really nice if Tapestry would use the s
There is a note on
http://tapestry.apache.org/integrating-with-spring-framework.html that says
that "you should consider the non-singleton beans to be not injectable.
Instead, inject the ApplicationContext service and obtain the non-singleton
beans as needed."
As for "seeing" multiple beans of the
On Fri, 18 Nov 2011 14:57:21 -0200, Michael Prescott
wrote:
I have a number of managed-by-Spring command objects that need to be
injected with the same (or an equivalent) state holder, otherwise yes,
I'd do exactly that. And by avoid, I'm not avoiding it like the plague,
I just liked the
I have a number of managed-by-Spring command objects that need to be
injected with the same (or an equivalent) state holder, otherwise yes, I'd
do exactly that. And by avoid, I'm not avoiding it like the plague, I just
liked the brevity of @Inject MyBean and it seemed within reach.
On 18 November
On Fri, 18 Nov 2011 12:51:45 -0200, Michael Prescott
wrote:
I was excited about the possibility of injecting a session-scoped Spring
bean into a dispatcher (since this saves mucking around with
ApplicationStateManager)
Why avoiding ApplicationStateManager? Quite easy to use and you avoid
I was excited about the possibility of injecting a session-scoped Spring
bean into a dispatcher (since this saves mucking around with
ApplicationStateManager) - but (of course!) I've run into a slight problem.
For whatever reason, this syntax:
..creates two visible beans of type MyBean in t
