Tamas, Rick did ask for a cleaner solution and, at least for Tomcat, using one class instead of many filters and session listeners (which Rick mentioned he is using now) looks like a cleaner solution to me.
Too bad he can't narrow it down to one SessionListener,without any Filters, for his webapp that does something like the following: When a session is created, have the SessionListener update a session count. If the count is 2 or more then call SessionEvent.getSession().invalidate() to cancel the session. Then the session listener's Session destroy method can decrement the counter appropriately. And once the main session is removed (via logout or timeout) it would set the session count back to zero so someone new could login to the webapp. But it sounds like Rick found some issues with that kind of approach where it doesn't match that simple kind of logic. Hell, if I were doing it I'd probably try to hide the one-session-only logic inside a Struts custom RequestProcessor.processRoles() (?) method call since I'm a processRoles()aholic programmer. :) Regards, David, full of way to many variations on ideas tonight. And I was so quiet for so many months. :( -----Original Message----- From: Tamas Szabo [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 26, 2005 11:45 PM To: Struts Users Mailing List Subject: Re: probably a cleaner way... testing for just one user Hi, >The theory is to override the PersistentManager with your own class. >Theirs subclasses the PersistentManagerBase which subclasses ManagerBase. >Now inside ManagerBase it seems to create the sessions in the method >createSession(String). If you override that, you could count the sessions >and if you already have one active, toss "IllegalStateException" to >prevent a second session from being created. > Rick did almost the same but using webcontainer indepenedent APIs. So why should he bind his implementation to Tomcat? I think that Rick's original solution is ok. He could remove some lines, because you can set/remove an attribute to/from a context and have that as a true, false flag. Instead of setting the attributes to false, don't set them or remove them and check only for attributes beeing present in the given scope, no need to check for their bool value. But that's only a minor detail... Tamas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
