Paul Sandoz wrote:
> Jeanfrancois Arcand wrote:
>> 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.
>>
>
> I worked around the problem.
>
> Basically the sleep statement after the starting the thread with
> 'selectorThread.startEndpoint()' was not waiting long enough and a race
> condition was occurring.
>
> The problem with this of course is that it does not guarantee to work
> around the problem. Different machines have different performance
> characteristics, we run the unit tests using Hudson on many different
> machines, plus we don't want to wait too long for the unit tests to
> complete :-) i left the waiting period to be one second...
Agree. I will take a look as soon as I can (I'm on travel for the next
two weeks, starting in Prague now :-)). We delayed the 1.7.0 promotion
until I can make it work on Jersey correctly...which mean I need o
execute soon :-)
>
> Incidentally it appears we have a similar problem with the LW HTTP
> server shipped with SE 6 Update 3 (but not with the http.jar shipped
> with Jersey). The LW HTTP server unit tests when run on SE 6 were
> blocking, Jakub put a sleep statement in after the server.start() and
> they work :-)
Interesting :-)
BTW I've realized that SelectorThread extends Thread (something I've
forgot for a long time), so the current code can be simplified....
More to come...
A+
-- Jeanfrancois
>
> Paul.
>
>> 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.
>>>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>