Hi,
I understand that the spec doesn't handle null values. As xml-rpc implements the SPEC, I find it completely valid, that null values are rejected *by default*. However, I can think of no reason why they shouldn't be supported *as a vendor extension*. Most of the other Apache software implementing specs do have vendor extensions (Xerces, Xalan, Tomcat, ...)
I've been bitten by that problem on two separate occasions now. It's a real pain in the rear......
The first time it happened about 2 months ago, I submitted a patch for DefaultTypeFactory to accept null values for integers, boolean, and doubles. That patch (along with another one to deal with more variants of ISO 8601 dates) was dropped/rejected/ignored.
The second time it happened, I used the undocumented, un-intuitive, "vendor extension" mechanism. Sample code below:
......
public class MyClassThatUsesXmlRpc {
static {
System.setProperty( TypeFactory.class.getName(),
"com.me.MySubclassOfDefaultTypeFactory" );
}
...
}
......Perhaps we should reconsider how best to deal with null values by default? --
Steve
------------------------------------------------------------
"Always ... always remember: Less is less. More is more. More is
better. And twice as much is good too. Not enough is bad. And too
much is never enough except when it's just about right."
-- The Tick
------------------------------------------------------------
