I was only opposed to this idea for filters because that's an unexpected behavior for most applications (multiple instances of the same filter class) and doesn't sound too intuitive for those accustomed to the traditional servlet model. If we dump the Filter approach (and have our own similar API concept for example), I think I could get on board for that.
I can't remember off of the top of my head how easy it would be to do what you've proposed INI config Kalle. If it was super easy for end-users, I'd definitely be open to that idea. But on a side note, I don't think setting request attributes is a bad thing or even orthogonal to the mutliple-filter-instances approach - it allows filters to 'talk' to each other in an unobtrusive way without requiring subclassing. Maybe this isn't needed at all with the multiple-filter-instance approach, but I haven't thought about if it'd be useful or not in that case. I'm gonna open another discussion thread about how we might be able to support the multiple-filter-instance approach cleanly and intuitively while still retaining backwards compatibility. Best, Les
