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.
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 question
----------------\
Paul Sandoz
x38109
+33-4-76188109