On Fri, Feb 11, 2011 at 11:11 AM, Les Hazlewood <[email protected]> wrote:
> On Fri, Feb 11, 2011 at 10:48 AM, Les Hazlewood <[email protected]> wrote:
>> As you know, Filters are currently maintained in a 'pool' from which
>> they can be referenced multiple times for separate chains. In every
Yes, and I'm saying there's no benefit pooling them.
>> For example, I can turn on or off the SSL filter application wide, but
>> then turn it on or off for an individual chain *without* removing it
>> from the chain:
>> /some/feature/** = ssl[enabled=${someFeature.ssl.enabled}], authc
>> I leverage this a lot in my apps and it allows for an extremely
>> powerful/flexible security control experience.
>> Creating a new filter instance per chain would be very frustrating if
>> I would have to configure the same filter type _every_ time it needs
>> to go in a chain. web.xml uses a single filter instance for multiple
Right, we have the default configuration per filter type and then
configuration per filter instance. Obviously the enabled bit is part
of the filter instance configuration.
Java's fast, but for a filter chain with five filters in it, we are
currently doing the same comparison five times unnecessarily. This
adds up very quick since it's done for every request. Just for fun, do
a few quick performance tests. In the meantime, I rescheduled the
issue for 2.0 and made it unassigned. For now, I'll instead implement
the same just for tapestry-security.
Kalle
