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
>