Hi,
to follow up I ended up solving this. I'll write out what I did if it
will be useful to others in the future.
I played around a bit with the Tapestry Request service object in the
AccessController dispatcher, I found out that the Session object will
carry object references to all SessionState objects. So I made a class
called UserId that tracks both the login id of the user and the session
type (I have multiple user interfaces for different DB entities so this
makes the UserId object unique in the system). When you login to one of
the interfaces you pass in the UserId and make it a SessionState object.
Now you can load this from the Request->Session->getAttribute(String)
method. Then you can do whatever you want to this, for example I
invalidate the session if you navigate outside of the interface to
elsewhere in the application. No need for storing the user id as a
string in the onPassivate context's like I previously thought. Who
thought refactoring could be so fun!
-Rich
On 08/26/2010 12:06 PM, Rich M wrote:
Hi,
I've been going through my code and doing some concurrency testing and
realized that the implementation of sessions I wrote back in the
beginning is very wrong. I had custom Session objects in the services
package to track user information and other things, but these really
don't belong in services themselves. To make matters worse, I was
using @SessionState on these Session objects, but since it's a service
this doesn't do what I had thought it would when I wrote the code.
So I'm thinking a better solution is to have session objects in a
seperate package and use a SessionManager to build the necessary
session objects on request from login pages and then these can be used
as @SessionState objects. This way, each actual browser session in the
application should have its own Session object assigned to it instead
of the broken shared Session object as before.
I am facing one issue though, in that I have a Dispatcher extending
class AccessController that was using the service-versions of the
Sessions to control some logic like invalidating sessions and such. It
just pulled them in through the constructor and figured which session
to use based on the page url. I'm having a hard time thinking how this
Dispatcher will be able to determine the session in use under the new
solution. I can inject the SessionManager in the constructor, but the
AccessController wouldn't know what session to request from the
SessionManager's collection anyway.
The first idea that comes to my mind is using the onPassivate to
return the userName to the URL context. I'm already parsing that
somewhat in the AccessController, so I should be able to get enough
info out of that to fetch the right session from the SessionManager. I
tried a quick implementation of this, but when I passivate a string
with "/" in it, the '/' gets converted to HEX and I don't like that.
Is there a way I can force it to render/output as '/' and not '002F'?
Any better suggestions as to implementation?
Thanks,
Rich
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
