users@jersey.java.net

Re: Grizzly Container is completely wrong, if I read it correctly

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Thu, 29 Nov 2007 12:51:11 +0100

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