Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <46CAEA85.3000608@christopherschultz.net>
Date: Tue, 21 Aug 2007 09:37:09 -0400
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: How to detect user logins
References: <46C95CDB.7030408@oma.be>
 <46C9B61B.1040806@christopherschultz.net> <46CA973F.8060904@oma.be>
In-Reply-To: <46CA973F.8060904@oma.be>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David,

David Delbecq wrote:
> Current strategy works (it's separated in 2 steps inside a common-chain
> of operation), but it makes wuite a few lines to try to detect user
> login, and if tomcat was already providing such event that could be
> handled by a context listener, that would have been, perhaps, cleaner.

How about an HttpSessionListener? It looks like what you really want is
a LoginListener or something like that, which doesn't exist in the spec.
You could always write your own Realm by subclassing an existing one and
adding such notification (or even stuff your magic "needs-upgrade"
object into the session.

I still don't think you'll be saving yourself that much work. Null
checks are cheap, and since they can be deployed on any app server and
any version (good luck when you upgrade Tomcat if you're subclasses the
Realm), I would recommend the more manageable solution over the
(potentially) faster one.

- -chris

> 
> En l'instant précis du 20/08/07 17:41, Christopher Schultz s'exprimait
> en ces termes:
>> David,
>>
>> David Delbecq wrote:
>>> For now, the layout is Filter that check userPrincipal. If user
>>> principal is not null for the first time, issues that check, mark
>>> that user got checked for next times, in session, and continue query.
>>>  However, if i could mark the session as "need upgrade" upon login,
>>> this would make things, i think, easier to manage as filter would
>>> only need to look for that "need upgrade" flag.
>> I think you'll find that you're just breaking your filter into two
>> separate filters: you'd have one that check to see if the session "needs
>> an upgrade", and then another one to "upgrade" it. Since the
>> functionality is all related, I'm not sure if there's a good reason not
>> to keep it all together.
>>
>> Do you have any particular complaints about your existing strategy?
>>
>> -chris
>>
> 
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGyuqF9CaO5/Lv0PARAvxHAJ0XQpmTm1mnS40M3E00n2izln9jWwCeIri/
dHKr3EGCZ5HxIs8whMb+LJ4=
=nrd+
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org