[undertow-dev] Retrieving request entity

[Miere Teixeira]

Hi Vladmir,

I've faced the same problem before, but reading each byte manually didn't
fit my needs.
When the JDK 1.4 released Java NIO API, they have already created a common
way to
read data with less development effort, I'm talking about
java.nio.channels.Channels class, which
has many helper methods able to convert data from old IO API to NIO API.

My prefered method is *Channels.newReader. *This method is able to convert
a StreamSourceChannel
to a lightweight Reader implementation. I like this method because many
object marshallers are
ready to handle Java IO Reader implementations.

Here is a sample implementation
<https://gist.github.com/miere/c2da3e8783e7db176097> with this approach.
Note: could be some typos as I've wrote this code manually to send this
mail.

I really hope it helps you.
Please Undertow devs let me know If I'm missing some important point on
this.

Regards.


On Mon, Aug 18, 2014 at 5:16 AM, Vladimir Tsukur <flushdia at gmail.com> wrote:

> Thanks for explaining the option with getRequestChannel! Got it working by
> reading content into a pre-allocated ByteBuffer.
>
> if it returns 0 register a read listener and call resumeReads()
>
>
> One thing I don't fully understand though is your note about registering a
> read listener (+ calling resumeReads) and why this is needed. Is it a
> mandatory step, and if it is, are you referring to application-specific
> read listener or Undertow's
> io.undertow.server.protocol.http.HttpReadListener? I guess this is pretty
> basic question, so it would be great if you can just point me to the right
> place at documentation, so that I can figure it out.
>
> Thinking about it we probably just need some way to buffer a
>> complete/partial message and then invoke a callback with the data.
>
>
> Yep, I guess this would be easier for the app developer to use.
>
>
> On Mon, Aug 18, 2014 at 2:34 AM, Stuart Douglas <sdouglas at redhat.com>
> wrote:
>
>> You can use the getRequestChannel() method to get the request channel.
>> Basically call read() on the channel till it returns either 0 or -1, if it
>> returns -1 you are done, if it returns 0 register a read listener and call
>> resumeReads().
>>
>> I have always been meaning to add a nicer non-blocking API for this, but
>> I have never been exactly sure what would be required here. Thinking about
>> it we probably just need some way to buffer a complete/partial message and
>> then invoke a callback with the data.
>>
>> Stuart
>>
>> Vladimir Tsukur wrote:
>>
>>> One of the ways to obtain request entity is to call
>>> HttpServerExchange.startBlocking and then read content from the
>>> HttpServerExchange.getInputStream.
>>>
>>> Is there a way to obtain request entity in a non-blocking way?
>>>
>>> --
>>> Vladimir Tsukur
>>> Software Architect, Design Engineer and Scrum Master
>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>
>
>
> --
> Vladimir Tsukur
> Software Architect, Design Engineer and Scrum Master
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140818/cba1bb9e/attachment-0001.html