users@jersey.java.net

Re: Possible bug in Grizzly <was> Re: Grizzly Container is completely wrong, if I read it correctly

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Thu, 29 Nov 2007 10:32:25 -0500

Salut,

Paul Sandoz wrote:
> Hi,
>
> I added some simple tests for HTTP methods, see:
>
> com.sun.ws.rest.impl.container.grizzly.HttpMethodTest
>
> When all tests are enabled all tests pass. However if i only enable the
> testPost test (which is the case for the unit test class in the trunk)
> then it fails.
>
> There appears to be an initialization issue with the Grizzly server
> w.r.t to a first HTTP request that contains a message body. Subsequent
> HTTP requests that contain a message body work fine. You can experiment
> by enabling/disabling and duplicating various tests.

OK I suspect the problem is with the GrizzlyRequest/ResponseAdaptor.
Will take a look.

Thanks

-- Jeanfrancois

>
> Paul.
>
> Paul Sandoz wrote:
>> Hi,
>>
>> I have integrated things into the trunk.
>>
>> The bug with the query string is because the URI constructor used URI
>> encodes URI component values, thus percent encoding was happening twice.
>>
>> I looked at the JavaDoc for:
>>
>> com.sun.grizzly.tcp.Request
>>
>> but there is no description for the URI information returned by these
>> methods:
>>
>> decodedURI()
>> requestURI()
>> unparsedURI()
>> query()
>> queryString()
>>
>> So i printed out all those values for a request at it appears
>> unparsedURI().toString() is a URI, in raw URI encoded form, containing
>> the URI path and URI query components.
>>
>> So i replaced all the code after constructing the base URI with:
>>
>> this.completeUri = baseUri.resolve(request.unparsedURI().toString());
>>
>> and the test now passes.
>>
>>
>> Some questions/comments:
>>
>> - do you have or intend to provide a core Grizzly jar rather than
>> four separate jars?
>>
>> - i am going to create a GrizzlyServer server factory so it is possible
>> to deploy resources and create and start a "default" SelectorThread in
>> just one line of code:
>>
>> SelectorThread thread =
>> GrizzlyServer.create("http://localhost:9997");
>>
>> - i notice that in the unit test you put a sleep statement after the
>> thread that calls the SelectorThread.startEndpoint is called. It would
>> be very useful to have a blocking method on SelectorThread that
>> started the endpoint in a new thread and waited until the endpoint
>> said it is ready. Another way is for the method to return a
>> Future<Boolean>.
>>
>> Paul.
>>
>> Jeanfrancois Arcand wrote:
>>> Salut,
>>>
>>> attached is the first patch. You will need to pullout the Grizzly's
>>> jat from here[1]. Why first, it's because there seems to be an
>>> encoding problem (which was also with Grizzly 1.0) I need to look at
>>> because a simple query test fail. I'm attaching the tests as well so
>>> you can take a look to see if the bug is in Grizzly or not. My guess
>>> is not. I think the way the response is constructed is the problem as
>>> bytes as written without any char to bytes conversion.
>>>
>>> At least now you can use Grizzly 1.6.x and find more bugs :-).
>>>
>>> Let me know what you think.
>>>
>>> A+
>>>
>>> -- Jeanfrancois
>>>
>>> [1] http://download.java.net/maven/2/com/sun/grizzly/
>>>
>>> Paul Sandoz wrote:
>>>> Jeanfrancois Arcand wrote:
>>>>>> My preference would be to only support the latest greatest stable
>>>>>> Grizzly.
>>>>>
>>>>> Agree...and the latest is faster :-)
>>>>>
>>>>> I've ported the code (it compile with the latest Grizzlies jars)...
>>>>
>>>> Great!
>>>>
>>>>
>>>>> now I don't recall how to test it (as usual)....any pointers of
>>>>> what I should run/try before submitting the patch will be helpful!
>>>>>
>>>>
>>>> Perhaps the best thing to do is copy a unit test from the LW HTTP
>>>> server.
>>>>
>>>> See the test package:
>>>>
>>>> com.sun.ws.rest.impl.container.httpserver
>>>>
>>>> and the classes:
>>>>
>>>> AbstractHttpServerTester
>>>> QueryParamTest
>>>>
>>>> You could copy these classes to the package
>>>>
>>>> com.sun.ws.rest.impl.container.grizzly
>>>>
>>>> and modify accordingly.
>>>>
>>>> Note that we do plan to improve the unit testing framework to make
>>>> it easy to test independent of the container but we are not their
>>>> yet so it is necessary to duplicate such tests.
>>>>
>>>> Paul.
>>>>
>>
>