users@grizzly.java.net

Re: Grizzly 2.0 filter chains and client side implementations

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Tue, 19 May 2009 15:01:40 +0200

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
>