Hi David,

thanks again for your time!

There is only one instance of your realm that is shared by all incoming
requests. That mean only local values inside methods are individual.
Every property that is stored at instance of class level is to be
accessed and stored in a ThreadSafe manner. It's up to you code to be
Threadsafe by assuming several Http Threads can run it at the same Time.

I am not so shure if I've a clear understanding of the realm architecture. So let me present my view of it:

Context --> Singleton?
Valve --> Singleton? Valve is the one who passes requests and responses
              objects
        Realm --> Singleton?
here I get requests and responses objects passing through the
                  Valve that wrapps the realm. A call of the    
                  request.getRemoteAddr() invokes the valve to get current
                  request informations, which is out of scope of the current
                  informations I get about the user in the realm (except
                  username and password, which are set in the callback handler).
                  How this is done? Which pattern is used, listener?

You can, however, make the assumption that the Thread that goes inside
your realm methods is the same that will serve your request. As such,
you can save datas for later use by same Thread using ThreadLocal.
Any example?
                

However, Threadlocal are to be used with caution. Do not forget to set
their value back to null our you could face a case of memory leak.
Ok.

Thanks!

-- Franck


En l'instant précis du 21/09/07 13:21, Franck Borel s'exprimait en ces
termes:
Salut David,

thanks very much for your answer!

 public SecurityConstraint[] findSecurityConstraints(Request request,
Context context) {
               HttpServletRequest req = request;    // catch Request
        session = req.getSession();          // catch session
        ipAddress = req.getRemoteAddr();

The problem:
In a first try this seems to work. But if more then one client try to
use the authentication, it catches the last IP address of the user who
makes a request and not the IP address of the current client I like to
authenticate:
So, the req.getRemoteAddr() seems to catch the information outside of
the current thread and I don't know why. Have someone an idea?
req.getRemoteAddres() will get the address of that specific request,
it's isolated from other simultaneous request, or lots of people would
start getting problems using it. I would be more enclined to take a look
at where you are defining the session and ipAddress properties, it looks
like they are class or instance level, where it's mandatory that Realm
be ThreadSafe and stateless.
This sounds like as my problem seems to be elsewhere as I supposed. I
have no idea where I should tell tomcat to keep the thread statefull.
I tried to set some page directives on my login.jsp:

<%@ session="true %> (which I think is standard)
<%@ isThreadsafe="false" %>

This doesn't help. Of course, it can't work, cause the Realm is a
valve and therefore the Realm is the part who calls the login.jsp page
and the directives of the page appears, in manner of speaking, "to late".

How can I tell the Realm to get ThreadSafe? Or have I missunderstood
something?


-- Franck

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



--

Beste Grüße

Franck Borel

**************************************************************************
Dipl.-Hyd. Franck Borel            Telefon: +49[0]761-203 3908
Universitätsbibliothek             Fax    : +49[0]761-203 3987
Werthmannsplatz 2                  E-Mail : [EMAIL PROTECTED]
                                   WWW    : http://www.ub.uni-freiburg.de
D-79098 Freiburg
**************************************************************************


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

Reply via email to