That should do the trick, thanks a lot. I'll give it a try with the 1.2 or 2.0 release.
P.S. I learn something new every day. I was unaware of the ThreadLocal class. Cool stuff. > -----Original Message----- > From: Adam Taft [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 10, 2006 4:49 PM > To: [email protected] > Subject: Re: Does this library provide a request context? > > Adam, > > I use an older version of the library (v 1.2-b1), so what I > do might not be the most accurate with the latest version > (though I assume it's practically the same). > > The basic authentication credentials are available by > implementing the AuthenticatedXmlRpcHandler interface (or > ContextXmlRpcHandler) in your handler class. So, if your > handler class implements this interface, the execute method > will be called with the client's username and password from > the basic authentication. > > From there, it's just a matter of looking up and validating > the credentials, matching it up to a user session, etc. I > basically keep some User objects cached in a Map, keyed off > of the username and password. Or, you could just go straight > to the database to lookup the user each request. > > Now, the interesting thing with this approach is that your > public methods in your handler class are now not "exposed" to > the client. When you implement one of the XmlRpcHandler > interfaces, the class isn't introspected for public methods. > What you can do though is call the Invoker class which will > then do the reflection just like the non-implementing "basic" > handler class would. > > So, your calculator class might look something like this > (note, I didn't compile this, just typing off the top of my head): > > > public class Calculator implements AuthenticatedXmlRpcHandler { > > // needed to store the current user in a thread safe way > private ThreadLocal<User> userThreadLocal = new > ThreadLocal<User>(); > > > public Object execute(String method, Vector params, > String username, > String password) throws Exception { > > // check username and password and store it > User user = getUser(username, password); > userThreadLocal.set(user); > > // use the Invoker on this class. > Invoker invoker = new Invoker(this); > Object obj = invoker.execute(method, params); > > return obj; > } > > public int add(int i1, int i2) { > // check the user > User user = userThreadLocal.get(); > user.checkSomeProperty(); > return i1 + i2; > } > > public int subtract(int i1, int i2) { > return i1 - i2; > } > } > > Obviously, in the example above, you'll need a supporting > User class. I > also end up storing the user in a ThreadLocal (as you can > see), so that > the methods (add, subtract) can get to the user object and change the > behavior of the method based on it. I tried to demonstrate > this above. > > Hope this helps. > > > Adam Bennett wrote: > > I've got the server and client example code working, (the > Calculator), > > and I enhanced it to use HTTP basic authentication. The > next thing I > > need is for the server to know which user is making the > request. For > > example, on the server we have: > > > > package videx; > > > > public class Calculator > > { > > public int add(int i1, int i2) > > { > > return i1 + i2; > > } > > > > public int subtract(int i1, int i2) > > { > > return i1 - i2; > > } > > } > > > > But instead lets say the result of the subtract() method > depends upon > > the user who is making the call. That is, the user > supplied during the > > authentication process. I know that if I can get the > HttpServletRequest > > object then I can query it for this information, but how do > I get at it? > > Is this possible with this library? > > > > The real need for this steams from the fact that each user has a > > different view of the data in our database and thus the > response will be > > different for each user. > > > > Thanks for your help on this. > > - Adam > > > > > > This message has been scanned by Symantec Mail Security for SMTP. > > > This message has been scanned by Symantec Mail Security for SMTP.
