Hi Henri,
I know a few people stuck to JDK 1.3 so JDK 1.4 as minimal requirement is not a safe bet.
Cheers,
Siegfried Goeschl
Henri Gomez wrote:
Why should we keep JDK 1.1 compatibility in XML-RPC 2.0 ?
If you take a look at majors ASF Java projects, like Tomcat 4/5, ant and others, the minimal JDK is now 1.4.
My point, say that 1.2 is the last release with JDK 1.1 support (as does Tomcat 3.3.x) and start 2.0 with JDK 1.4 in mind.
There is more use of XML-RPC in B2B transaction, server to server, than applet to server.
On Wed, 30 Mar 2005 16:09:51 -0800, Steve Quint <[EMAIL PROTECTED]> wrote:
At 10:52 PM +0100 3/30/05, Andrew Evers wrote:
I've looked at your patches, and I think that they both deserve
inclusion in some form. The patch to DateTool really does need tests to
go with it, dates are extra-ordinarily difficult things (I work for a
scheduling company, I KNOW!).
I checked my outbox. I sent an unit test as a file attachment, and it must have been rejected by the mailing list software. I've inlined it at the end of this message.
Would preventing randomly thrown Exceptions when parsing bad/weirdBeing able to put up with erroneous interpretations of the specification
XML-RPC responses be considered "useful"? I don't want to get into a
discussion about how everyone should adhere strictly to the spec.
There are different interpretations of the spec, and I can't change
everyone's interpretations of it. All I know is that I need the
library to work with vendor X, and I think my changes would help
anyone else who wants to work with vendor X.
is certainly an advantage. I'd rather have the option of specifying the
'default' value for cases where the cdata is null or empty. This would
also provide behaviour for dates and strings as well. Watch this list
for a patch to DefaultTypeFactory that allows this.
Having an option sounds good, as long as the TypeFactory doesn't throw NullPointerExceptions when dealing with the data.
I *have* been able to work around the problem by using theWhich encoding issue? The default input encoding stuff I fixed today?
"sufficient support" in the current API you mentioned, until I ran
into the encoding issue. Thanks for the patch.
Yes, although I'm not using it for EBCDIC. I need it to handle non ASCII strings in responses that do not correctly identify the encoding in the XML declaration.
Unit test below: ============================================================ package org.apache.xmlrpc.util;
/* * The Apache Software License, Version 1.1 * * * Copyright (c) 2001 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in * the documentation and/or other materials provided with the * distribution. * * 3. The end-user documentation included with the redistribution, * if any, must include the following acknowledgment: * "This product includes software developed by the * Apache Software Foundation (http://www.apache.org/)." * Alternately, this acknowledgment may appear in the software itself, * if and wherever such third-party acknowledgments normally appear. * * 4. The names "XML-RPC" and "Apache Software Foundation" must * not be used to endorse or promote products derived from this * software without prior written permission. For written * permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called "Apache", * nor may "Apache" appear in their name, without prior written * permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * ==================================================================== * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * <http://www.apache.org/>. */
import java.text.ParseException; import java.util.Date;
import junit.framework.Test; import junit.framework.TestCase; import junit.framework.TestSuite;
/** * Unit test for DateTool parser. * * @author squint * @version $Version: $ */ public class DateUtilsTest extends TestCase { // These dates are all equivalent. private static final String[] LOCAL_DATES = { "20040413T11:07:32", "2004-04-13 11:07:32", };
private static final String[] TEST_DATES = { "20040413T09:07:32Z", "2004-04-13T10:07:32+01:00", "2004-04-13T20:07:32+1100", "2004-04-13T09:07:32Z", };
/** * Inform JUnit of this test suite. */ public static Test suite() { return new TestSuite( DateUtilsTest.class ); }
/** * Test the local dates without time zone information. */ public void testLocalDates() { DateTool tool = new DateTool(); Date date1 = null; Date date2 = null; try { date1 = tool.parse( LOCAL_DATES[0] ); date2 = tool.parse( LOCAL_DATES[1] ); } catch(ParseException e) { } assertEquals( date1, date2 ); }
/** * Test dates with time zone information. */ public void testTZDates() { DateTool tool = new DateTool(); try { Date date1 = tool.parse( TEST_DATES[0] ); assertEquals( date1, tool.parse( TEST_DATES[1] ) ); assertEquals( date1, tool.parse( TEST_DATES[2] ) ); assertEquals( date1, tool.parse( TEST_DATES[3] ) ); } catch(ParseException e) { } } }
--
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 ------------------------------------------------------------
