I have a project where I need some services session scoped, not
singletons or perthread. The reason is that I have some web services
I use that need some session state for initialization. While the
perthread approach works just fine, I don't want to be initializing
that stuff with every request. Calling out to wslds and all the xml
mumbo jumbo is resource intensive.
I got it working is a short period of time, I thought I just send this
out in case anyone else has the same need down the line.
What I did was essentially copy the perthread approach and modify from
there. Under the covers the perthread stuff essentially just uses a
threadlocal map to store the services, I swapped that out for a
@SessionScope map, and then modified the cleanup logic, as I no longer
need to cleanup at a thread level. In my case, I have a very specific
use case that resets the session state, so I basically call out a
PerSessionManager.cleanup() method directly. I would imagine for the
general case, the creation of a new session or expiration of an old
session would automatically clean things up.
So in your service you simply annotate like this:
@Scope(PerSessionServiceLifecycle.PERSESSION)
public class SakaiScriptServiceImpl extends AbstractSakaiService
implements SakaiScriptService {
then you need to use a builder method approach for ioc, b/c the
autobinding is not aware of session scoped items, only proper
services, at least that what I've seen in practice. I have both a
@SessionState item and a @SessionAttribute item I need, so I pass in
the ApplicationStateManager and Request object to pull those out and
create my service like this:
public static SakaiScriptService
buildSakaiScriptService(ApplicationStateManager stateManager, Request
request)
{
com.rsmart.dashboard.entities.System system =
stateManager.get(com.rsmart.dashboard.entities.System.class);
return new SakaiScriptServiceImpl(getSakaiSessionId(request), system);
}
The delayed instantiation of services until they are needed made this
possible. This is my first tapestry project, and I just continue to
be impressed. It took a bit of research to sort through it, but it
really wasn't that bad. Prior to this I was having to manually
initialize my services in all the page code, and that was annoying the
heck out of me. I'll sleep much better tonight. If this is generally
useful to anyone let me know I can send the full code.
If anyone has creative ideas on how I could further limit having to
create a build method for each service, enlighten me, I'm sure that
can be improved, but I'm happy enough with this for now.
--
John Bush
602-490-0470
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
