> As far as my original attempts to get the interceptors patch noticed,
> you can find some of the history here:
> http://marc.theaimsgroup.com/?a=93724818900001&r=1&w=2
I just looked over the patch, and it seems to me to be inverting things
a little. An XmlRpcRequest is really a part of a larger outer request
that has come in via HTTP. The HTTP request is really the context in
which the XML-RPC occurs. It is also imaginable that an XML-RPC may
not come in via HTTP (message-oriented-middleware anyone?).
Putting HTTP specific information into the request is problematic
because it violates layering (slightly), but it also means that
everyone that embeds the XML-RPC package in a HTTP implementation
needs to modify their code to support the new execute methods.
There are a number of people embedding the XmlRpcServer without using
the WebServer. The recent patch I made makes it possible to embed
XML-RPC into an arbitrary HTTP implementation that already handles
threads (eg. a servlet engine, or a different lightweight HTTP
implementation).
An alternative method that should require less modification to the core
XML-RPC code is to pass around a context object (either an Object, or
a _very basic_ XmlRpcContext interface) passed in to the execute(*)
methods in XmlRpcServer and XmlRpcWorker. The current execute(*)
methods would call the new methods with context = null.
Then, add a factory method in XmlRpcServer to create XmlRpcWorker
instances:
protected XmlRpcWorker createWorker()
{
return new XmlRpcWorker(handlerMapping)
}
- return new XmlRpcWorker(handlerMapping);
+ return createWorker();
Now, you can subclass WebServer, XmlRpcServer and XmlRpcWorker to
create a framework with all the filtering you like. There is no
interface (or performance) impact for people not needing the
extra features, but they are available if required. You can now
pass around arbitrary context information (maybe SSL connection
information) for use by the worker, with minimum impact to
the rest of the framework.
You can even pass the context object right into the handling
object if you create extended versions of the XmlRpc<X>Handler
interfaces, or a parallel XmlRpcContextHandler interface with
a setContext() method.
Andrew.
