can you just shoot me the link where I can take a look of a testcase for
that ?
I'll start soon Grizzly 2..
2009/1/8 Survivant 00 <survivant00_at_gmail.com>
> thanks
>
> so just to resume. the Thread will loop until the terminating sequence is
> found, and if the terminating sequence is not found in the message, it will
> put in back in the context and wait for the next message .. right ? (just
> to be sure)
>
>
>
> 2009/1/8 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>
>
> Hi Sebastien,
>> I've added this possibility.
>> So now it's possible to annotate String message member following way:
>>
>> public static class TerminatingStringMessage {
>> private byte a;
>>
>> @CharSequence(terminate="<eos>")
>> private String b;
>> private int c;
>> }
>>
>> So the String will be encoded and decoded using "<eos>" as terminating
>> sequence.
>>
>> Hope this will help you.
>>
>> WBR,
>> Alexey.
>>
>>
>> On Dec 17, 2008, at 14:00 , Survivant 00 wrote:
>>
>> yes that will be enough.
>>
>> 2008/12/17 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>
>>
>>> Hi Sebastien,
>>>
>>> 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 .
>>>
>>> Agree.
>>> This could be useful to have such a feature.
>>> Actually I was thinking about implementing special Codec for Strings,
>>> which have termination symbol or seq. of symbols like '\0' or "<eos>. I
>>> think this could be enough for your protocol, right?
>>>
>>> WBR,
>>> Alexey.
>>>
>>>
>>>
>>>
>>>
>>> 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
>>>>
>>>>
>>>
>>>
>>
>>
>