On 02/16/2012 06:30 PM, Matthew Swift wrote:
> 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 ;-)
Sure, it's what we planned.
> I can also verify that Ryan's fixes for GRIZZLY-1190 and GRIZZLY-1191
> seem to work ok.
Great!!!
Thanks.
WBR,
Alexey.
>
> On 16 February 2012 13:42, Oleksiy Stashok <oleksiy.stashok_at_oracle.com
> <mailto: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 <mailto: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
>>
>
>