Hi Alexey,
Any more example about message codec? It look a little bit difficult to me.
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.