Ok, for JDK 1.3.x as minimal JRE/JDK
On Thu, 31 Mar 2005 11:41:47 +0200, Siegfried Goeschl <[EMAIL PROTECTED]> wrote: > 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 > >>------------------------------------------------------------ > >> > >> > >> > > > > > > > >
