Last thing about this... I found something about performance: I did it
with de "tapestry-hibernate way", this is using the PerThreadManager.
I thought it was going to be the same or better, but NO, it's the
*same* as doing the RequestFilter way, I mean, for every asset (js,
css) it will try to clos
In my case I don't open the session programatically, the session opens
when it's needed (getCurrentSession() bounded to current thread). I
think the only diference is closing the session... I do it inside the
dispatcher, and tapestry-hibernate is better (as you say) because it
closes when the threa
I think you're going at this the wrong way, in this particular instance.
I think you'd be better off to do this the way tapestry-hibernate does
it. Basically, you instaniate the session the first time it's needed,
and then use PerThreadManager to clean up the session at the end of
the thread
Answering to myself :)
It is possible to *override* dispatchers... in this case, I did
override "PageRender".
In contributeMasterDispatcher(...) I added :
configuration.overrideInstance("PageRender", MyDispatcher.class);
where MyDispatcher is the similar to PageRenderDispatcher (default)
but
Hi, I made a dispatcher for web-security and it really works fine. As
I'm not using tapestry-hibernate, I want to create a dispatcher for
opening and closing hibernate-sessions.
By now I did it with a RequestFilter and works fine, the problem is
that the RequestFilter filters *everything*, assets,
