Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <38FE4D57.C3A232F1@costin.dnt.ro>
Date: Wed, 19 Apr 2000 17:20:39 -0700
From: Costin Manolache <costin@costin.dnt.ro>
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: authorization providers (was More on JAAS)
References: <Pine.SOL.4.10.10004191349530.5340-100000@techunix.technion.ac.il>
 <38FDF5EF.E7D91349@eng.sun.com> <38FE4718.C13B8E5A@costin.dnt.ro>
 <38FE49CA.7101FFE7@eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> The issue I was addressing is, where do I keep state information specific to
> this particular interceptor related to this particular request?  Because
> there's only one instance of the interceptor (so you cannot use instance
> variables unless you internally key things by thread), and you cannot use
> local variables (they go away as each handler method returns) to keep state
> information from one handler method to the next handler method in that same
> interceptor.
>
> It's not that you cannot store state information for this purpose -- it's
> just a little more complicated to have to use something like request
> attributes for things that are (from a logical perspective) private to this
> interceptor.

The local variables are visible only inside invoke(). That means even inside
the same Valve - you can't share them, but just use inside the invoke() method.

Having local variables inside a method ( that are used before and after
the method pass control to the next one in chain) is not so much "less
complicated", and I don't think  it should be on the list of "requirements" for
a
servlet container or subject to "feature comparation" between 2
patterns ...


Costin