Hi
>> public static final int PORT = 7778;
>> public void testStandaloneFilter() throws Exception {
>> Connection connection = null;
>> TCPNIOTransport transport =
>> TransportManager.instance().createTCPTransport();
>> transport.getFilterChain().add(new TransportFilter());
>> transport.getFilterChain().add(new UTFStringFilter());
>> transport.getFilterChain().add(new EchoFilter());
>
> We still need to discuss the getFilterChain() names ;-)
:) ok
>> try {
>> transport.bind(PORT);
>> transport.start();
>> ConnectFuture future =
>> transport.connectAsync("localhost", PORT);
>> connection = (TCPNIOConnection) future.get(10,
>> TimeUnit.SECONDS);
>> assertTrue(connection != null);
>> String message = "Hello world!";
>> FilterChain filterChain = transport.getFilterChain();
>> WriteResult result = filterChain.write(connection,
>> message);
>> assertEquals(result.getMessage(), message);
>> ReadResult readResult = filterChain.read(connection);
>
> OK I'm not sure about this example. It seems we first works with the
> Transport object and then switch to the FilterChain. If the
> FilterChain handler the read/write logic, why not the connectAsync
> be on the FilterChain as well?
Well, I'm not trying to move transport logic to filterchain. I'm just
showing how it's possible to use filterchain in standalone mode.
How data could be read from the connection, pass the filterchain and
finally we will have filterchain processed message (String in our case).
> Also, the connet() operations returns A Future, where read/write
> return a Read/WriteResult. Should read/write return a Future as
> well? I would propose we unify the API so any async operations like
> connect/read/write return a Future. From the Future, we can return a
> Result, which contains the requested information. Something like:
connectAsync is async operation, that's why it returns Future.
read/write are blocking - that's why Result.
readAsync/writeAsync operations return Future<Result>.
So, IMHO, it's we don't have unification problems :)
> Result result = ConnectFuture.get()
> Connection connection = result.getResult()
>
> or
>
> Connection connection = ConnectionFuture.get(..) //No cast needed
that casting was redundant. Fixed.
>
> ReadResult result = ReadFuture.get();
> WriteResult resukt = WriteFuture.get();
>
> So your example seems to "suffer" 2 issues:
>
> + Need one single Object to interact with.
transport logic is inside Connection. And FilterChain just brings
processing logic.
The connection.read() in our example will return ByteBuffer, but
filterchain.read() will return String (as result of UTFStringFilter).
> + Unify API for async operations.
it's not problem :)
>> String responseMessage = (String) readResult.getMessage();
>> assertEquals(message, responseMessage);
>> } finally {
>> if (connection != null) {
>> connection.close();
>> }
>> transport.stop();
>> TransportManager.instance().close();
>
> I still find it dangerous to have 2 operations to execute here :-)
> But maybe it is only me :-)
No, no, you may be right. Just didn't time to revisit this.
Thanks!
WBR,
Alexey.
>
>
> A+
>
> -- Jeanfrancois
>
>
>
>> }
>> }
>> }
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>