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
>>>
>>>
>>
>>
>
>