Hi Alexey and Ryan,
Switching to the FilterChainBuilder seems to resolve the
ArrayIndexOutOfBoundsException problem. Perhaps it would be a good idea to
make the DefaultFilterChain class package private and also, as you suggest,
make FilterChains immutable in order to avoid misuse by people like me ;-)
I can also verify that Ryan's fixes for GRIZZLY-1190 and GRIZZLY-1191 seem
to work ok.
Thanks :-)
Matt
On 16 February 2012 13:42, Oleksiy Stashok <oleksiy.stashok_at_oracle.com>wrote:
> Sorry, I wasn't accurate when reading your initial post.
> You're not trying to modify existing filterchain at runtime.
>
> Can I suggest to change it this way:
>
> void installFilter(final Filter filter)
> {
> synchronized (stateLock)
> {
> // Updates to the filter chain cannot be synchronized with
> traversals, so
> // copy on write.
> FilterChain oldFilterChain = (FilterChain) connection.getProcessor();
> FilterChain newFilterChain = FilterChainBuilder.stateless()
> .addAll(oldFilterChain)
> .add(oldFilterChain.size() - 1, filter)
> .build();
> // FilterChain newFilterChain = new
> DefaultFilterChain(oldFilterChain);
>
> // Install the filter in the new filter chain beneath the LDAP
> filter.
> // newFilterChain.add(newFilterChain.size() - 1, filter);
> connection.setProcessor(newFilterChain);
> }
> }
>
>
> Thanks.
>
> WBR,
> Alexey.
>
>
> On 02/16/2012 12:29 PM, Matthew Swift wrote:
>
>
>
> 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
>
>
>