Salut,
Paul Sandoz wrote:
> Hi,
>
> I have integrated things into the trunk.
Merci!
>
> 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:
Yes. We gonna release Grizzly 1.7.0 this week and the next release will
be an only 'improve documentation release'
>
> 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.
Right.
>
> So i replaced all the code after constructing the base URI with:
>
> this.completeUri = baseUri.resolve(request.unparsedURI().toString());
>
> and the test now passes.
Great.
>
>
> Some questions/comments:
>
> - do you have or intend to provide a core Grizzly jar rather than
> four separate jars?
>
Official release can be downloaded as a zip file from here (1.7.0 will
most probably be release tomorrow):
http://download.java.net/maven/2/com/sun/grizzly/bundles/
But based on your feedback, I will start doing a single jar file like I
was doing for Grizzly 1.0.x. so no needs to download many 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>.
That's a good idea. I did put the sleep to make sure the server is
started. Let me try to have that in 1.7.0.
Thanks
-- Jeanfrancois
>
> 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.
>>>
>