Subject: Re: bug-to-bug compatibility - another issue - msg#00930

Previous Message by Date: click to view message preview

Re: local test server (Was: Re: [jira] Commented: (HARMONY-71) java.net.URLConnection.setUseCaches throws unspecified IllegalAccessError)

Hi Richard, Yes, I'm always for simplifying testing routine. And creating a detail guide for configuring some testing server is a possible way to do it. However I'd prefer to try to develop a simple local test server that is easy to configure. I believe that it will cover most of cases. And I assume that there may be a number of sophisticated test cases that requires a special server set up. But I'd place them separately this was discussed in '[testing] code for exotic configurations' topic. Otherwise there is a chance to get the following detailed instructions: 1) Download http server from http://www.apache.org ... 50) Do this and that ... 100) Now you can run net tests Thanks, Stepan On 2/22/06, Richard Liang <richard.liangyx@xxxxxxxxx> wrote: > > Dears, > Agree that server (maybe not local) is required for some sophisticated > test cases. To make thing simply, we may provide more detail guide > (step-by-step) on how to setup/configure a typical testing server. Or > shall we setup a test server and allow user to share our testing server? > > Richard Liang > China Software Development Lab, IBM > > > > Tim Ellison wrote: > > Stepan Mishura wrote: > > > >> I glanced through a local server code from HARMONY-57 contribution > without > >> looking into implementation details and ... this made me think. I catch > hold > >> of the following: > >> 1) The server contains some testing code that looks not good for me > >> > > > > Care to explain? > > > > > >> 2) It is not as simple as I expected - my impression was that a local > server > >> implementation should be very simple because we are not going to test > >> whether it corresponds to http spec. or not. IMHO, it should only > provide a > >> test case with: > >> - a port number to open communication > >> - access to a server's input/output streams to verify a request to a > server > >> or to form a server's response. > >> Naive? Well, I'm aware that I'm not so experienced in java.netdevelopment > >> and testing and may be I'm wrong. > >> > > > > The local server I referenced can be used for a number of the java.net > > tests, some of which do require more sophisticated behavior, like basic > > authentication, eTags, etc. > > > > I agree that the tests in HARMONY-71 only need something to accept their > > connection, but I was simply pointing out that there will be a local > > server we can use if that contribution is accepted into the project, so > > probably not worth writing another. > > > > > >> I'd like to start with the first issue (BTW, is it ok to discuss > details of > >> contribution implementation if it is not accepted yet?). > >> > > > > Sure -- I would expect people to be evaluating it thoroughly so that > > they can vote the code in/out. The PPMC will shout early if the > > paperwork implies a contribution is unacceptable. > > > > > >> Can we avoid adding > >> a code that is specific for some test case to a local server? > >> > > > > Does it interfere with what you want to do? > > In some cases, the test case needs to know what is on the server a > > priori, so that it can test the client behavior correctly. > > > > Regards, > > Tim > > > > > >> On 2/16/06, Tim Ellison wrote: > >> > >>> I would rather that you just opened a new JIRA issue for that as it > >>> doesn't relate to the original problem. > >>> > >>> FYI there is a local server incoming in the HARMONY-57 contribution, > so > >>> don't spend any time on it, see: > >>> > >>> > <HARMONY-57>\Harmony\Harmony_Tests\src\test\java\tests\support\Support_HttpServer.java > >>> > >>> Regards, > >>> Tim > >>> > >>> Stepan Mishura (JIRA) wrote: > >>> > >>>> [ > >>>> > >>> > http://issues.apache.org/jira/browse/HARMONY-71?page=comments#action_12366637 > ] > >>> > >>>> Stepan Mishura commented on HARMONY-71: > >>>> --------------------------------------- > >>>> > >>>> Tim, > >>>> > >>>> Added test case (test_setUseCachesZ) depends on network and it fails > if > >>>> > >>> it can not create connection with apache.org. The same for HARMONY-72. > I'm > >>> going to attach a patch file with a local server in it. Could you > reopen > >>> this JIRA? > >>> > >>>> Thanks, > >>>> Stepan. > >>>> > >>>> > >>>>> java.net.URLConnection.setUseCaches throws unspecified > >>>>> > >>> IllegalAccessError > >>> > -------------------------------------------------------------------------- > >>> > >>>>> Key: HARMONY-71 > >>>>> URL: http://issues.apache.org/jira/browse/HARMONY-71 > >>>>> Project: Harmony > >>>>> Type: Bug > >>>>> Components: Classlib > >>>>> Reporter: Svetlana Samoilenko > >>>>> Assignee: Tim Ellison > >>>>> According to j2se 1.4.2 specification method > >>>>> > >>> java.net.URLConnection.setUseCaches(boolean) throws > IllegalStateException, > >>> if already connected. Harmony throws java.lang.IllegalAccessErrorinstead, > >>> that contradicts the specification. > >>> > >>>>> Code to reproduce: > >>>>> import java.io.IOException; > >>>>> import java.net.*; > >>>>> public class test2 { > >>>>> public static void main(String[] args) { > >>>>> HttpURLConnection u=null; > >>>>> try { > >>>>> u=(HttpURLConnection)(new URL("http://intel.com > >>>>> > >>> ").openConnection()); > >>> > >>>>> u.connect(); > >>>>> } catch (MalformedURLException e) { > >>>>> System.out.println("unexpected > MalformedURLException"+e); > >>>>> } catch (IOException f) { > >>>>> System.out.println("unexpected IOException"+f); > >>>>> } > >>>>> try { > >>>>> u.setUseCaches(true); > >>>>> } catch (IllegalStateException e) { > >>>>> System.out.println("OK. Expected IllegalStateException"); > >>>>> e.printStackTrace(); > >>>>> }; > >>>>> } > >>>>> } > >>>>> Steps to Reproduce: > >>>>> 1. Build Harmony (check-out on 2006-01-30) j2se subset as described > in > >>>>> > >>> README.txt. > >>> > >>>>> 2. Compile test2.java using BEA 1.4 javac > >>>>> > >>>>>> javac -d . test2.java > >>>>>> > >>>>> 3. Run java using compatible VM (J9) > >>>>> > >>>>>> java -showversion test2 > >>>>>> > >>>>> Output: > >>>>> C:\tmp>C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2 > >>>>> java version "1.4.2_04" > >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05 > ) > >>>>> BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build > >>>>> > >>> ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: > parallel) > >>> > >>>>> OK. Expected IllegalStateException > >>>>> java.lang.IllegalStateException: Already connected > >>>>> at java.net.URLConnection.setUseCaches(Z)V( > URLConnection.java > >>>>> > >>> :828) > >>> > >>>>> at test2.main([Ljava.lang.String;)V(test2.java:17) > >>>>> C:\tmp>C:\harmony\trunk\deploy\jre\bin\java -showversion test2 > >>>>> (c) Copyright 1991, 2005 The Apache Software Foundation or its > >>>>> > >>> licensors, as applicable. > >>> > >>>>> java.lang.IllegalAccessError: Connection already established > >>>>> at java.net.URLConnection.setUseCaches(URLConnection.java > :923) > >>>>> at test2.main(test2.java:17) > >>>>> Suggested junit test case: > >>>>> ------------------------ > URLConnectionTest.java------------------------------------------------- > >>>>> import java.io.IOException; > >>>>> import java.net.*; > >>>>> import junit.framework.*; > >>>>> public class URLConnectionTest extends TestCase { > >>>>> public static void main(String[] args) { > >>>>> junit.textui.TestRunner.run(URLConnectionTest.class); > >>>>> } > >>>>> public void test_setUseCaches () { > >>>>> HttpURLConnection u=null; > >>>>> try { > >>>>> u=(HttpURLConnection)(new URL("http://intel.com > >>>>> > >>> ").openConnection()); > >>> > >>>>> u.connect(); > >>>>> } catch (MalformedURLException e) { > >>>>> fail("unexpected MalformedURLException"+e); > >>>>> } catch (IOException f) { > >>>>> fail("unexpected IOException"+f); > >>>>> } > >>>>> try { > >>>>> u.setUseCaches(true); > >>>>> } catch (IllegalStateException e) { //expected > >>>>> }; > >>>>> } > >>>>> } > >>>>> > >>> -- > >>> > >>> Tim Ellison (t.p.ellison@xxxxxxxxx) > >>> IBM Java technology centre, UK. > >>> > >>> > > > > > > -- Thanks, Stepan Mishura Intel Middleware Products Division

Next Message by Date: click to view message preview

Re: bug-to-bug compatibility - another issue

On 2/22/06, Paulex Yang <paulex.yang@xxxxxxxxx> wrote: [snip] > > But the spec of CharsetDecoder.flush() says: > > Throws: > IllegalStateException - If the previous step of the current decoding > operation was an invocation neither of the reset method nor of the > three-argument decode method with a value of true for the endOfInput > parameter > > It's so interesting that the spec emphasizes it SHOULD NOT throw > IllegalStateException when flush() just after reset(). > > In fact, this is just one example of contradiction between spec and RI's > CharsetDecoder/Encoder internal status implementation. These *bugs* are > serious so that the RI's Decoder/Encoder must be used by experiment. > Should Harmony be compatible with RI? Hi Paulex, I have no deep knowledge in this area and therefore cannot really judge the possible impact. My opinion is from common sense only: - spec DEFINITELY states exception should not be thrown and people DEFINITELY take this into account - I cannot believe applications really EXPECT this exception to detect this particular scenario and do something specific for the case flush() is called after reset(). Most likely application just stop processing if exception occur. Exception is terated as a 'signal that something is wrong'. - I cannot find what is wrong in calling flush() after reset(). Looks like quite normal operation. Spec proves that. My opinion here - to follow the spec. At least unless we really have an application failing on that (what I personally hardly believe to happen). -- Anton Avtamonov, Intel Middleware Products Division

Previous Message by Thread: click to view message preview

bug-to-bug compatibility - another issue

Following the discussion before, I have another issue about RI's "bug", try this little test below: import java.nio.charset.*; public class DecoderTest{ public static void main(String[] args){ CharsetDecoder decoder = Charset.forName("utf-8").newDecoder(); decoder.reset(); decoder.flush(CharBuffer.allocate(10)); } } It quits quietly on Harmony, while on RI(JDK 5.0/1.4.2), it throws exception like below: java.lang.IllegalStateException: Current state = RESET, new state = FLUSHED at java.nio.charset.CharsetDecoder.throwIllegalStateException(Unknown Source) at java.nio.charset.CharsetDecoder.flush(Unknown Source) ........ But the spec of CharsetDecoder.flush() says: Throws: IllegalStateException - If the previous step of the current decoding operation was an invocation neither of the reset method nor of the three-argument decode method with a value of true for the endOfInput parameter It's so interesting that the spec emphasizes it SHOULD NOT throw IllegalStateException when flush() just after reset(). In fact, this is just one example of contradiction between spec and RI's CharsetDecoder/Encoder internal status implementation. These *bugs* are serious so that the RI's Decoder/Encoder must be used by experiment. Should Harmony be compatible with RI? -- Paulex Yang China Software Development Lab IBM

Next Message by Thread: click to view message preview

Re: bug-to-bug compatibility - another issue

Mikhail Mikhail Loenko wrote: Paulex, look at the class description in the spec: "A decoder should always be used by making the following sequence of method invocations, hereinafter referred to as a decoding operation: Reset the decoder via the reset method, unless it has not been used before; Invoke the decode method zero or more times, as long as additional input may be available, passing false for the endOfInput argument and filling the input buffer and flushing the output buffer between invocations; Invoke the decode method one final time, passing true for the endOfInput argument; and then Invoke the flush method so that the decoder can flush any internal state to the output buffer. " As I said, what I paste at first is just ONE Example that RI's interesting internal status. I happened to have another simple JUnit test to show RI's contradiction on the paragraph above public void testFlushAfterDecode() throws Exception { ByteBuffer in = ByteBuffer.wrap(new byte[] { 98, 98 }); CharsetDecoder decoder = Charset.forName("utf-8").newDecoder(); CharBuffer out = decoder.decode(in); try { decoder.flush(out); fail("should illegal"); } catch (IllegalStateException e) { } } RI(JDK 5.0/1.4.2) failed to pass this test because the flush(out) is permitted, but from the spec above, the decoder.decode(in) should invoke flush method at last, and the current status is FLUSHED, so that the flush(out) after that should throw IllegalStateException. Should Harmony be same with RI again? So RI works according to class description. It might be a misprint in the method description you have cited. I'd rather be compatible with RI Thanks, Mikhail I'm afraid I have different view on this, First, the method spec is not contradict with class's, the flush(CharBuffer) should be invoked in the decode(ByteBuffer), that's right, and it also can be invoked just after reset(), any logic problem? Second, how can we judge JavaDoc is misprinted? just by RI's behavior? On 2/22/06, Paulex Yang <paulex.yang@xxxxxxxxx> wrote: Following the discussion before, I have another issue about RI's "bug", try this little test below: import java.nio.charset.*; public class DecoderTest{ public static void main(String[] args){ CharsetDecoder decoder = Charset.forName("utf-8").newDecoder(); decoder.reset(); decoder.flush(CharBuffer.allocate(10)); } } It quits quietly on Harmony, while on RI(JDK 5.0/1.4.2), it throws exception like below: java.lang.IllegalStateException: Current state = RESET, new state = FLUSHED at java.nio.charset.CharsetDecoder.throwIllegalStateException(Unknown Source) at java.nio.charset.CharsetDecoder.flush(Unknown Source) ........ But the spec of CharsetDecoder.flush() says: Throws: IllegalStateException - If the previous step of the current decoding operation was an invocation neither of the reset method nor of the three-argument decode method with a value of true for the endOfInput parameter It's so interesting that the spec emphasizes it SHOULD NOT throw IllegalStateException when flush() just after reset(). In fact, this is just one example of contradiction between spec and RI's CharsetDecoder/Encoder internal status implementation. These *bugs* are serious so that the RI's Decoder/Encoder must be used by experiment. Should Harmony be compatible with RI? -- Paulex Yang China Software Development Lab IBM -- Paulex Yang China Software Development Lab IBM