Salut,
Jacob Kessler wrote:
> Sure, I can add users_at_grizzly.
>
> I was hoping to test the Jython module without bringing up the whole
> grizzly infrastructure, but passing in valid HTTP bytes could work, as
> long as I could store that valid request and clone/modify it as needed
> for each of the tests. I'd have to go generate the request from a
> capture of a real packet, though.
Then you need to either manually provision the Request/Response object
or extends GrizzlyRequest/Response claa.
>
> The module to be tested is an extension of GrizzlyAdapter, and I'd like
> the testing harness to be able to convince the module that it is living
> down at the bottom of glassfish (the way it is supposed to) and that a
> GrizzlyRequest has just arrived at its overridden
> service(GrizzlyRequest request,GrizzlyResponse response) method,
> preferably with as little overhead and setup as possible. I was thinking
> of setting the required properties through the set___ methods on
> GrizzlyRequest and GrizzlyResponse, but if you think that having Grizzly
> parse bytes would work better, I can definitely do that.
Let us know what will be your final solution as I would think peoples
here might be interested to use your work for testing purpose.
Thanks!
-- Jeanfrancois
P.S Nice to see Jython on Grizzly!!
>
> Jeanfrancois Arcand wrote:
>> Salut,
>>
>> (cc-ing tech for sharing..can we have the discussion on users_at_grizzly?
>> Nice topic IMO)
>>
>> Jacob Kessler wrote:
>>> I'm writing unit tests for the new Glassfish Jython module, and I'd
>>> like to be able to generate Grizzly requests and responses so that I
>>> can test the module in isolation (and without using the network).
>>
>> This is a great idea.
>>
>> Can you tell me
>>> what properties I'll need to set on a brand-new GrizzlyRequest (from
>>> GrizzlyRequest req = new GrizzlyRequest();) to simulate something
>>> like an HTTP/GET request, and similarly the properties I'll need to
>>> set on the response to read back the application's reply? Is there a
>>> better way to accomplish this testing? Thank you in advance.
>>
>> You need to work with those two objects:
>>
>> utils/src/main/java/com/sun/grizzly/tcp/Request
>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/tcp/Request.html
>> utils/src/main/java/com/sun/grizzly/tcp/Response
>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/tcp/Response.html
>>
>> Those object then gets wrapped within GrizzlyRequest/GrizzlyResponse.
>> Take a look at
>>
>> utils/src/main/java/com/sun/grizzly/tcp/http11/GrizzlyAdapter
>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/tcp/http11/GrizzlyAdapter.html
>>
>>
>> to see how they get wrapped.
>>
>> Now take a look at
>>
>> http/src/main/java/com/sun/grizzly/http/ProcessorTask
>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/http/ProcessorTask.html
>>
>>
>> to understand how to populate the Request object and to prepare the
>> response. One easy way for you could consist of provisioning an
>> InputReader:
>>
>> utils/src/main/java/com/sun/grizzly/InputReader
>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/util/InputReader.html
>>
>>
>> and pass it to ProcessorTask. Just put valid http request bytes inside
>> the ByteBuffer associated with the InputReader. To make it happens,
>> you might want to extend the
>>
>> http/src/main/java/com/sun/grizzly/http/SelectorThread#configureFilters(...)
>>
>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/http/SelectorThread.html#718
>>
>>
>> and inject your provisioning Filter that will fake a socket:
>>
>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/filter/ReadFilter.html
>>
>>
>> So long email to recommend you override configureFilter with your own
>> ReadKindOfFilter. Provision that Filter and it should emulate a normal
>> http request, assuming the bytes are well http formed.
>>
>> Hope that help.
>>
>> -- Jeanfrancois
>>
>>
>>
>>
>