On 16 February 2012 11:27, Oleksiy Stashok <oleksiy.stashok_at_oracle.com>wrote:
> [...]
>
> Frankly saying, I was planning to make FilterChain immutable, so it
> would be created once using Builder and then you'll not be able to update
> it.
> Otherwise, if we make FilterChain mutable (properly mutable) and
> thread-safe - it may cause significant performance degradation.
>
> The easy way to work it around is to add *all* Filters to the chain in the
> beginning and then introduce some boolean Attribute inside given Filter and
> check whether Connection has already passed Filter's specific checking or
> not, if yes - immediately return context.getInvokeAction(); and pass
> control to the next filter in chain.
>
> Will appreciate your feedback on this :)
>
>
I understand and what you're suggesting should satisfy our current
requirements.
I was hoping to allow users of our library to be able to add in their own
simple custom filters if they want. For example, compression, as well as
SASL security. I don't know in advance what they might want, nor how many
place holders to have for them. In this case, and based on what you're
saying, do you think that it would make sense if I implemented this using
some sort of composite filter, i.e. a Filter containing zero or more
sub-filters? The sub-filters would not be Grizzly Filters but instead our
own abstraction instantiated on a per connection basis and responsible for
managing their own internal state. Would there be any implications to this
approach?
Matt