that's really nice.
is it possible to do the same thing with a variable length message ?
you could have a annotation for the start (probably not needed) or the end
of query.
a message is completed when you found the eoq. and if you reach the max
buffer size(annotation) you throw a Exception ? (maxBuffersize..)
that will save me 200 lines of code for the parser in 1.x .
2008/12/16 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>
>
>> Hi Emit,
>
> coming back to your question, if it's not late...
>
> What is the best "grizzly 2.0" way to cut up the incoming stream
>> into these logical packets of data, hopefully without editting
>> the grizzly internal classes? I guess I can just aggregate
>> these getMessage Buffers myself after the handleReads but in that
>> case I don't see a reason to use this framework with all the
>> overhead involved.
>>
> Yesterday we've added new feature in Grizzly 2.0, which may help you with
> message parsing.
> Please take a look here [1]
>
> Thanks.
>
> WBR,
> Alexey.
>
> [1]
> http://www.nabble.com/Grizzly-2.0%3A-Smart-codec-td21033363.html#a21033363
>
>
>>
>> I think it would be helpful if you could show how to build upon
>> the example EchoFilter to only echo back lines of text. i.e.
>> '\n' would mark end of message, and a string would be the logical
>> unit. (so even from windows telnet it will only echo back on new
>> line, instead of on each character typed)
>>
>> Regards,
>> -Emit
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>