Multiple instances of the same Filter class across filter chain definitions

[Les Hazlewood <lh...@apache.org>]

I'd like to resurface Kalle's approach to using multiple instances of
the same filter class across different matching URL pattern filter
chains.

Currently today, the same filter instance is used across multiple
chains, for example:

[main]
# configure 'myFilter' here:
myFilter.foo = bar
myFilter.blah = whatever

[urls]
# use the 'myFilter' in multiple filter chains:

/some/path/** = myFilter, x, y, z, ...
/another/path/** = myFilter, a, b, c, ...

Under Kalle's approach, each path would have its own individual
instance of the 'myFilter' class, instead of a single instance being
shared across chains as it is done today.

Kalle, how do you propose that end-users would configure the
multi-instance approach in INI?

For example, objects are typically instantiated and configured in
[main] and then referenced in [urls].  How would that be different
with your approach?

Thanks!

Les

Re: Multiple instances of the same Filter class across filter chain definitions

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Jun 26, 2011, at 10:10 PM, Les Hazlewood wrote:

> This looks pretty cool Alan.  We could also do this in INI by
> introducing a meta concept:
> 
> [main]
> ...
> myFilter = com.foobar.whatever[scope=prototype]
> 
> where 'scope=singleton' would be the default to retain current
> behavior.  This would turn 'myFilter' (and any of its property
> settings) into a 'definition' object and not the object itself.  Then
> each time it is instantiated (per filter chain perhaps), the
> definition is translated into an instance at that time.

Yeah, this is better than specifying it in an annotation.


Regards,
Alan

Re: Multiple instances of the same Filter class across filter chain definitions

[Les Hazlewood <lh...@apache.org>]

On Sun, Jun 26, 2011 at 10:10 PM, Les Hazlewood <lh...@apache.org> wrote:
> This looks pretty cool Alan.  We could also do this in INI by
> introducing a meta concept:
>
> [main]
> ...
> myFilter = com.foobar.whatever[scope=prototype]

I just realized this is essentially the same thing as Kalle's previous
suggestion (using a period as a prefix to trigger a 'template').  This
could work well.  And if you still wanted chain-specific config, we
could probably support something like this:

/some/path/** = myFilter[prop1=value1, prop2=value2, ...], x, y, z, ...

That way you can override individual properties that may not match the
template/prototype definition in the [main] section.  That sounds
pretty sweet to me.  Thoughts?

Cheers,

Les

Re: Multiple instances of the same Filter class across filter chain definitions

[Les Hazlewood <lh...@apache.org>]

This looks pretty cool Alan.  We could also do this in INI by
introducing a meta concept:

[main]
...
myFilter = com.foobar.whatever[scope=prototype]

where 'scope=singleton' would be the default to retain current
behavior.  This would turn 'myFilter' (and any of its property
settings) into a 'definition' object and not the object itself.  Then
each time it is instantiated (per filter chain perhaps), the
definition is translated into an instance at that time.

Just thinking out loud...

Les

Re: Multiple instances of the same Filter class across filter chain definitions

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Jun 26, 2011, at 2:09 PM, Les Hazlewood wrote:

> I'd like to resurface Kalle's approach to using multiple instances of
> the same filter class across different matching URL pattern filter
> chains.
> 
> Currently today, the same filter instance is used across multiple
> chains, for example:
> 
> [main]
> # configure 'myFilter' here:
> myFilter.foo = bar
> myFilter.blah = whatever
> 
> [urls]
> # use the 'myFilter' in multiple filter chains:
> 
> /some/path/** = myFilter, x, y, z, ...
> /another/path/** = myFilter, a, b, c, ...
> 
> Under Kalle's approach, each path would have its own individual
> instance of the 'myFilter' class, instead of a single instance being
> shared across chains as it is done today.
> 
> Kalle, how do you propose that end-users would configure the
> multi-instance approach in INI?
> 
> For example, objects are typically instantiated and configured in
> [main] and then referenced in [urls].  How would that be different
> with your approach?

For me, I like having the control of creating the instance outside of the filter chain definition.  Maybe if there's a method in the filter that follows a signature

public Filter allocate();

or is annotated:

@FilterFactory
public Object fubar();

then the framework could create instances per path.  With the annotation we can be a bit more creative:

@FilterFactory(FilterInstance.PER_REQUEST)
public Object fubar();


Regards,
Alan

Re: Multiple instances of the same Filter class across filter chain definitions

[Kalle Korhonen <ka...@gmail.com>]

I wouldn't necessarily change anything in the ini syntax. If you had:
/some/path/** = myFilter[someconfiguration], x, y, z, ...

only "someconfiguration" would be instance specfic. "myFilter" would
have to be read as an alias for the filter rather than an instance.
That wouldn't allow calling setters on the instance though. If that's
too limiting, we could have:
myFilter = com.company.web.some.FilterImplementation
.FilterImplementation.foo = bar
myFilter.foo = blah

and:
/some/path/** = .FilterImplementation, x, y, z, ...
/another/path/** = myFilter, a, b, c, ...

The dot denotes a filter "template". A naive implementation would just
use static operations on the filter class (but it doesn't have to be
implemented that way). In this syntax, it wouldn't be allowed to use
myFilter (the instance) in a different chain.

Kalle


On Sun, Jun 26, 2011 at 2:09 PM, Les Hazlewood <lh...@apache.org> wrote:
> I'd like to resurface Kalle's approach to using multiple instances of
> the same filter class across different matching URL pattern filter
> chains.
>
> Currently today, the same filter instance is used across multiple
> chains, for example:
>
> [main]
> # configure 'myFilter' here:
> myFilter.foo = bar
> myFilter.blah = whatever
>
> [urls]
> # use the 'myFilter' in multiple filter chains:
>
> /some/path/** = myFilter, x, y, z, ...
> /another/path/** = myFilter, a, b, c, ...
>
> Under Kalle's approach, each path would have its own individual
> instance of the 'myFilter' class, instead of a single instance being
> shared across chains as it is done today.
>
> Kalle, how do you propose that end-users would configure the
> multi-instance approach in INI?
>
> For example, objects are typically instantiated and configured in
> [main] and then referenced in [urls].  How would that be different
> with your approach?
>
> Thanks!
>
> Les
>

Re: Multiple instances of the same Filter class across filter chain definitions

[Kalle Korhonen <ka...@gmail.com>]

On Sun, Jun 26, 2011 at 2:13 PM, Les Hazlewood <lh...@apache.org> wrote:
> Also, Kalle, why do you think this might be a better approach than
> using request attributes to reflect path/request-specific
> configuration?  I'm curious as to the thought process as this diverges
> from the 'traditional' servlet model.

Using request attributes would have other interesting benefits, like
sharing same configuration between different filters, but to answer
your question: it's better because it'd be simpler to implement (less
lines of code) and it would perform better. I think it's a typical
case for trading memory for better performance. Obviously, it's not
like other suggested implementations would perform drastically worse,
but on the hand fairly limited number of multiple filter instances
don't consume that much more memory either. So together with the
simplified implementation, it seems like a reasonable win without
major drawbacks.

Kalle

Re: Multiple instances of the same Filter class across filter chain definitions

[Les Hazlewood <lh...@apache.org>]

Also, Kalle, why do you think this might be a better approach than
using request attributes to reflect path/request-specific
configuration?  I'm curious as to the thought process as this diverges
from the 'traditional' servlet model.

Thanks,

Les