On Fri, 13 Sep 2002, Andrew Evers wrote:
> > 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. Well, nothing I have done is HTTP-specific per se. The XmlRpcRequest mods I posted on Wednesday include a generic headers Properties object in the XmlRpcRequest object. Currently, since HTTP is the *only* transport at this point (and in fact, it looks like the spec binds XML-RPC to HTTP, if I'm reading it right), those are the "headers" which are populated. But there is nothing to say that whatever is responsible for the transport layer, cannot write the "headers" and populate the headers on the server side in whatever fashion it chooses. For instance, if for some reason there was an SMTP transport, I'd imagine SMTP headers could be written to the headers object, including custom application headers. This is the same way the Servlet spec works: you have a generic ServletRequest and ServletResponse (at this time I don't think we need an XmlRpcResponse), and all handling revolves around them. > 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). Is this patch committed? Or can you point me to it. I probably won't get a good idea of what you are saying unless I see the code. > 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. If you are proposing a pluggable transport and worker classes that's fine by me. The mods I made don't really effect the functionality of the code in XmlRpcWorker, it just adds header accumulation and in the case of interceptors some extra callbacks. I suppose I could extend and override XmlRpcWorker if there was a way to plug my implementation in XmlRpcServer (getWorker()). Just to be clear, is there something specific about my patch Wednesday ("more refactoring with XmlRpcRequest") besides the deprecation of the execute(<params>) calls in favor of execute(XmlRpcRequest). Note, I /did not/ force XmlRpcHandler to use XmlRpcRequest...invoker still invokes as execute(methodName, params) and I have no intention of changing this (although if developers want access to this on the server side, we might want to provide some mechanism for getting the XmlRpcRequest). For my Wednesday patch, the developer API is not even changed besides the deprecation of the XmlRpcServer execute(<params>), which can be easily be un-deprecated to assuage fears. I think it is nicer to put a bit more data in XmlRpcRequest (including headers), and handle that class solely, instead of the various types of execute() calls we have internally. It also allows us to extend functionality without adding extra parameters to calls, since we can just add it to XmlRpcRequest. It may just be a matter of opinion. I'm not tied to Wednesday's patch, I just thought it was a decent next step in refactoring. Aaron
