If this code is moving along I'd like to see a pre-alpha of it so I can rewrite my Jakarta Commons HttpClient piece to use the framework we are talking about. Any chance you could send me your source?
--
Ryan Hoegg
ISIS Networks
Andrew Evers wrote:
Instead of an XmlRpcClientContext class, I would instead suggestI like it. Done.
writing an XmlRpcTransport interface that is then implemented by each
of our HTTPTransport classes:
public interface XmlRpcTransport() {
public InputStream executeRequest(URL url, byte[] requestBody);
}
I'm also going to add a FixedInputStream class that wraps an
InputStream and returns -1 for read() past a length specified in the
constructor. This allows exceptions to work properly (instead of
blocking indefinitely on the socket read()).
XmlRpcClient would then get a new method:
public void setTransport(XmlRpcTransport transport)
The version I am working on at the moment has an XmlRpcTransportFactory responsible for creating XmlRpcTransport instances. You can create an XmlRpcClient using any of the usual constructors, in which case you get the default transport factory. You can also specify a transport factory to one of the constructors.The XmlRpcClient will call its transport factory for each XML-RPC made via execute(String, Vector) and execute(XmlRpcRequest) this will create a connection for each XML-RPC made. If you call execute(XmlRpcRequest, XmlRpcTransport) then your specified transport will be used instead. If you want to use a persistent connection, you can use an XmlRpcTransport from somewhere else (probably an external factory), and pass this into the execute method on the client yourself. Andrew.
