passing information to the underlying httpClient

Our application has two tomcat server; TomcatA uses Spring remoting (apache commons HttpClient) to make service/remote calls to tomcatB.

Users connect to tomcatA and that's where there credentials are validated; The current interfaces/api to the remote methods does not provide for any facility for passing any additional parameters/arguments and our requirement is now to pass the user credentials (or at least the username) to tomcatB from tomcatA for logging purposes as to which user invoked the remote method.
Is there anyway that we can pass each user's information when the application invokes the remote method to the underlying commons http client via the spring framework so that it can be retrieved at the server (tomcatB) ?

Any suggestions are appreciated, Many thanks

There is an obvious AOP solution: wrap both the client and sever side in a Proxy - on the client to add the user credentials to the call, and one on the server to log them and delegate to the real remote service.

Thanks for the reply david_syer.

AOP was the first thing that popped up in our collective minds as well :) but unfortunately it is not an option as it has not yet been approved for use in our org.

You can't use java.lang.reflect.Proxy? If you can, then the good news is that that is what Spring AOP uses. If you can't for some bizarre reason (how would anyone know?), then the bad news is that you're already using it with HttpInvoker.

What's the best way to wrap the client in a proxy? Implement my own httpInvokerRequestExecutor, containing an HttpClientFactoryBean?

Or is there an easier way?

I would wrap your client in a Proxy with some advice that adds the user credentials (nothing to do with http invoker). Then expose a different interface using HttpInvoker, adding the client credentials as an extra argument.

Sorry about the AOP ignorance (I'll fix that very soon), but when you say expose a different interface using HttpInvoker, is there a way to do that generically so I don't have to affect the "real" underlying service?

e.g. I have 10 services that can be called internally within my app or externally. I only want to audit this client information when a service is called externally. Do I need to add another method that includes the extra argument explicitly to each of those 10 services, or can I do that transparently with AOP? (And is that appropriate in this case in your opinion)? Thanks again.

So the remote service is under your control (I assumed so at first, but not so sure now)? Generally HttpInvoker is only useful whe nyou have control of both client and server, so maybe I am still correct in thinking so.

You do need "new methods", but the point of the AOP idea is that you don't put them in the original service interface (and since you want to use that internally this would seem to be ideal). You put them in a new interface which you then expose remotely - the user credentials are going to have to go over the wire somehow. The goal is that the clients (local and remote) should be able to work with the same "real" service interface without the extra argument.

Thanks - I think I understand. Yes, I do have control over the remote service. I was hoping to be able to send and process this extra client information for all of our services in a generic fashion, but this is still pretty clean. I was hoping there was a slick way to weave in the client metadata totally transparently (without explicitly creating any new interfaces), but it sounds like it's not an option.

At any rate, it sure beats SOAP.