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
