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 <[email protected]> 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 >
