XmlRpcClientLite has a built-in "light" HTTP client implementation, which
I presume is supposed to be lighter than the Apache or Sun HTTPClient.
Headers themselves won't be that useful if you can't do something with
them on the server side so there must be something analogous to read them
off at the server side. Interceptors (or filters, or hooks, whatever
youw ant to call them, basically just a callback mechanims) only deals
with mutating a call that is underway. So yes, I'd expect you'd want to
expose the headers functionality at the client end...through something
like setHeaders()/setHeader()/getHeaders()/getHeader(). On the server
side however, there is no server endpoint per se...the endpoint is your
XMLRPC server class, so to make the headers available to your code (not
just an interceptor) there would have to be some sort of mapping set up,
probably based on thread, e.g.:
public class ContextMapping {
private ContextMapping() {}
private static Hashtable contexts = new Hashtable();
public static void setContext(XmlRpcRequest req) {
contexts.put(Thread.currentThread(), req);
}
public static XmlRpcRequest getContext() {
return contexts.get(Thread.currentThread());
}
// would be necessary to remove mapping so threads don't
// hang around; alternative is Weak references
public static void clearContext() {
contexts.remove(Thread.currentThread());
}
}
Server side interceptor or request parsing code:
// read request from socket
// create XmlRpcRequest with headers
ContextMapping.setContext(req);
Your XML-RPC server class:
public String saySomething(Vector arguments) {
XmlRpcRequest theRequest = ContextMapping.getContext();
String userAgent = theRequest.getHeader("User-Agent");
String whatToSay = theRequest.getHeader("whatShouldISay");
return "You called with " + arguments.size() + " arguments "
+ "with user agent: " + userAgent + ", and passed a "
+ "header that told me to say: " + whatToSay;
}
Obviously that is a completely contrived example. The patch I posted
yesterday would leave this possibility open.
Aaron
-------------------------------
[EMAIL PROTECTED] wrote:
>If the intent is for the HTTP client component by the Apache group to be
>the single entry point on the client side, I'm all for it. It has been
>tedious to maintain two sets of similar changes between XmlRpcClient and
>XmlRpcClientLite. While the interceptors patch may be large, the patch I
>posted yesterday is smaller and includes code which accumulates and reads
>headers on both the client (both clients) and server side. Does Apache
>have an HTTP server component that also returns headers? It's all fine
>and good to be able to modify headers on the client side...but something
>needs to read them on the server side also. You are right, the
>headers/XmlRpcRequest issue, introspection, and interceptors are somewhat
>orthogonal...it just so happened that code in my interceptors patch also
>added the ability for modification of headers...this can of course be
done
>independently of interceptors.
>
>Aaron Hamid
>
Well I have been careful not to modify the XmlRpcClientLite class
because I am not familiar with the goals of it. I am making
modifications exclusively to XmlRpcClient.
The best I have been able to find in Apache's software for a java HTTP
Server component is in Tomcat: the Catalina connector package. In my
current project, the XML-RPC server I am using already supports (and in
fact requires!) HTTP/1.1 chunking, compression, and cookies. Obviously
it will be advantageous for this library to support these things too,
but this will be separate from the client process. Understand, there is
more to this than just custom headers.
I am starting to "get" this interceptor thing... and it sounds like a
good idea. I just think it will be kind of a "hack" to do HTTP headers
with it.
--
Ryan Hoegg
ISIS Networks
