users@grizzly.java.net

Re: Grizzly 2.0 M3: multi-binding requires other than SingletonFilterChainFactory

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Tue, 16 Jun 2009 17:00:35 +0200

Hi,

> The TCPNIOTransport uses a SingletonFilterChainFactory:
>
> ...
> PatternFilterChainFactory patternFactory =
> new SingletonFilterChainFactory();
> FilterChain filterChain = new
> DefaultFilterChain(patternFactory);
> patternFactory.setFilterChainPattern(filterChain);
>
> filterChainFactory = patternFactory;
> ...
>
> which makes it 'hard' to create a multi-bind server with different
> FilterChain's. I now use this for every ServerConnection:
>
> PatternFilterChainFactory factory = new SingletonFilterChainFactory();
> filterChain = new DefaultFilterChain(factory);
> ...
>
> Which is against the idea behind a factory.
I just updated FilterChain implementations, so it doesn't require
Factory to be passed in constructor.

>
> Of course I could create another Factory that implements
> FilterChainFactory,
> but I think this should be in the framework itself. But not through
> the
> TCPNIOTransport class!, since the processor is related to the
> ServerConnection and not to the Transport.
>
> So it would be better, in my opinion, if something like this would be
> possible:
>
> Connection serverConnection = m_transport.bind(sAddress, iPort);
> ...FilterChainFactory factory =
> serverConnection.getFilterChainFactory(); //
> anything, but NOT a SingletonFilterChainFactory!
> ...FilterChain filterChain = factory.create();
> --
I see your idea, but as I said in one of prev. mails, I see
ServerConnection as just subclass of Connection and not sure about
idea of having filter chains or thread pools to be set per
ServerConnection. In this case, IMHO, it could make sense to use
separate transport instance. What do you think?

WBR,
Alexey.


> View this message in context: http://www.nabble.com/Grizzly-2.0-M3%3A-multi-binding-requires-other-than-SingletonFilterChainFactory-tp23939701p23939701.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
>