In our case Collections are Java 2, so even 1.2.x should be needed :) JDK 1.4.x could be usefull when palying with NIO and many optmized conversions functions.
NIO may not be usefull since XML-RPC is often embedded in a servlet engine (ie tomcat), where such goodies are allready available underneath. Conversions are also available even when JDK 1.4.x is not available, ie some are found in jakarta-tomcat-connectors. Regards On Thu, 31 Mar 2005 11:47:53 +0200, Nicolas De Loof <[EMAIL PROTECTED]> wrote: > > Please notice Websphere 5.0 is runs on JDK 1.3. It is used as shared > production platform for some of my customers, so will not upgrade to 1.4 > before a long time. > > Jdk 1.3 API should be good enough for lot's of enhancements, as lot's of > JDK 1.4 API are available as optionnal JDK 1.3 extensions (XML parser, > JSSE encryption...) > > Siegfried Goeschl a écrit : > > > 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/weird > >>>>> 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. > >>>>> > >>>> > >>>> Being able to put up with erroneous interpretations of the > >>>> specification > >>>> 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 the > >>>>> "sufficient support" in the current API you mentioned, until I ran > >>>>> into the encoding issue. Thanks for the patch. > >>>>> > >>>> > >>>> Which encoding issue? The default input encoding stuff I fixed today? > >>>> > >>> > >>> 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 > >>> ------------------------------------------------------------ > >>> > >>> > >> > >> > >> > >> > > > > > > This message contains information that may be privileged or confidential and > is the property of the Capgemini Group. It is intended only for the person to > whom it is addressed. If you are not the intended recipient, you are not > authorized to read, print, retain, copy, disseminate, distribute, or use > this message or any part thereof. If you receive this message in error, > please notify the sender immediately and delete all copies of this message. > >
