ine);
-String method = tokens.nextToken();
-String uri = tokens.nextToken();
-String httpVersion = tokens.nextToken();
-keepAlive = XmlRpc.getKeepAlive()
+ // only do this if we *might* have a valid header --
michael lankh
Title: RE: Interceptors/Introspection patch
I think the introspection patch is really exciting!
Too bad I have not heard about this before!
Introspection allows you to browse the public interface and the parameters of the methods.
Inteception allows you to intercept any call and debug the ca
Title: RE: Interceptors/Introspection patch
Good Question!
I have been asking myself that.
And what is introspection but the programatic access to the IDL/Description/Interface?
Here is what I found.
Please excuse all the links, but this is just raw data:
ALIDI: http://www.xmlrpc.com/alidl
"
Jim,
>>So, simplying saying that we return an "array" is not useful. It could be
>>described in a DTD, that is, I think that one could describe it in a DTD
>>(_one_, not necessarily me), but it would be a challenge to then convert
>>that to C++.
After my research over the weekend, I think th
? The
documentation is sparse, so I am not sure where to look
thanks,
Michael
--
Michael Guymon
Senior Developer
Igicom
[EMAIL PROTECTED]
When choosing between two evils, I always like to take the one I've
never tried
before. -- Mae West, "Klondike Annie"
rong, which happens once in a while). Is there a more
formal RFC, or a document that is more explicit about the formating?
thanks,
--Michael
Chris Jackson wrote:
We have a functioning implementation of SecureXmlRpcTransport and
DefaultXmlRpcTransportFactory with a very permissive X509TrustManager
(no cert checking or hostname verification)
well done! would've saved me a week or two of programming as I learned
the code, read O'Re
Oded,
I needed more flexibility too.
I just created my own XmlWriter implementation and modified XmlRpc to use a class
specified at runtime.
Modify XmlRpc.java - Add the following 3 methods and a static member (xmlWriterClass)
//++ START CODE SNIPPET +
/** ***
>
>On Monday 18 October 2004 18:29, Andrew Evers wrote:
>> The use of these types comes from our desire (and our users desire)
>> to work with Java 1.1, often in Applets in a web browser. This
>> unfortunately means that the more abstract collections framework
>> introduced in 1.2 is not availabl
