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