Hi Ken,
>
> Any more example about message codec? It look a little bit difficult
> to me.
Hmm, I don't have much examples on Codecs :(
Codec basically consists of encoder and decoder Transformers, Here you
can take a look at StringEncoder and StringDecoder implementations
https://grizzly.dev.java.net/source/browse/grizzly/branches/2dot0/code/modules/grizzly/src/main/java/org/glassfish/grizzly/util/StringDecoder.java?view=markup
https://grizzly.dev.java.net/source/browse/grizzly/branches/2dot0/code/modules/grizzly/src/main/java/org/glassfish/grizzly/util/StringEncoder.java?view=markup
After J1 I'll try to come with some Codec + Streams example.
Thank you.
WBR,
Alexey.
>
>
> Thanks and Best Regards,
> Ken
>
>
>
> Oleksiy Stashok wrote:
>>
>> Bo,
>>
>> BTW, filterChain.getCodec() should work now.
>> So, all Filters in a FilterChain, which implement CodecFilter will
>> take part in message transformation.
>>
>> WBR,
>> Alexey.
>>
>> On May 19, 2009, at 15:56 , Bo Li wrote:
>>
>>> Ahh... Now it all makes sense. I saw all the codec related code in
>>> the repo but don’t see how they can be used. This should work for
>>> the client side and I like the message abstraction since we do that
>>> now anyways. I guess the encode transform calls the filters from
>>> last to first and the decode from first to last? What will the
>>> decode side look like? Is the codec API designed as a replacement to
>>> the filter / handleRead/Write methods of implementing custom
>>> protocols? How do you think it will affect performance and memory
>>> use?
>>>
>>> Grizzly 2.0 is getting very interesting and I can’t wait to see the
>>> next set of changes!
>>>
>>> Thanks again
>>> Bo
>>>
>>>
>>> On 5/19/09 3:01 PM, "Oleksiy Stashok" <Oleksiy.Stashok_at_Sun.COM>
>>> wrote:
>>>
>>>> Hi Bo,
>>>>
>>>> looks like you're looking for Codec API to be supported by
>>>> FilterChain (FilterChain.getCodec()).
>>>> We have that API, but it's not implemented for FilterChain. I'll
>>>> complete the implementation nearest time.
>>>>
>>>> It will work like:
>>>>
>>>> Buffer buffer =
>>>> filterChain.getCodec().getEncoder().transform(message);
>>>> connection.getStreamWriter().writeBuffer(buffer);
>>>>
>>>> This way, tranform will sequentially call each Filter, which
>>>> implement FilterCodec interface, to encode the message.
>>>>
>>>> Does this sound good for you?
>>>>
>>>> WBR,
>>>> Alexey.
>>>>
>>>>>
>>>>> I have a question about the design of client side code, or any non
>>>>> IO event
>>>>> driven code, using Grizzly 2.0. I understand that processing is
>>>>> triggered on
>>>>> IO events and each filter in the filter chain will handle the
>>>>> event
>>>>> accordingly. This works well in a server-side request-response
>>>>> protocol
>>>>> model. The protocol parser can just read and write to the
>>>>> StreamReader and
>>>>> StreamWriters from the FilterChainContext without having knowledge
>>>>> of
>>>>> previous filters on the chain.
>>>>>
>>>>> However, what I don't see is how to do the same on the client side
>>>>> or if the
>>>>> server needs to send unsolicited messages to the client. In these
>>>>> cases,
>>>>> there are no IO events to trigger the filter chain but the
>>>>> protocol message
>>>>> still needs to be handled by the filters before going out the
>>>>> wire. I
>>>>> understand for SSLFilter I can just wrap the SSLStreamWriter
>>>>> around
>>>>> StreamWriter from the TCPConnection but then my protocol parser
>>>>> code will
>>>>> need to know about the previous filters on the chain and their
>>>>> implementation. If I change the filters in the chain I will also
>>>>> need to
>>>>> change the wrappings of StreamWriters and StreamReaders.
>>>>>
>>>>> Is there a easier way to do this? I envision a two-way filter
>>>>> chain where I
>>>>> just write to "protocol" side of the chain and previous filters
>>>>> will process
>>>>> the write request before sending it out the wire.
>>>>>
>>>>> Thanks again
>>>>> Bo
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>
>>>>
>>>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Grizzly-2.0-filter-chains-and-client-side-implementations-tp23615467p23757013.html
> Sent from the Grizzly - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>