Actually, in thinking about this more, I don't think we should create new Filter instances per chain by default, and here's why:
1. Shiro filter chains can contain _any_ javax.servlet.Filter instance - not just Shiro PathMatching ones. Just like web.xml, we create a single Filter instance used in many chains. This ensures that we remain consistent with the Servlet specification and we retain the singleton nature that everyone expects. 2. Creating a new Filter instance per chain can be a dangerous thing to do - there are many filters that, upon startup/init, go through sometimes significant initialization logic resulting in final state used when filtering requests. For example, consider the Spring DispatcherServlet - it creates an ApplicationContext at filter startup. While many instances of this could be created (and it probably would't be too expensive), it is not expected that this would ever occur, and it could even result in problems for some applications. This is just one example. There are a ton of other framework filters that assume the same 'init once' behavior. Because we can't know before hand what Filters would be used in Shiro's chain definitions, we can't just assume to create a new instance for each chain. I don't know what Tapestry Security supports, but if you're allowed to configure any javax.servlet.Filter like you can in Shiro's INI, I think you'd be opening yourself to many potential problems since creating new instances per chain is definitely not standard Serlvet container behavior. Finally, and please correct me if I'm wrong, but your main concern in this thread isn't really about new instances vs pooled instances (if it was, I'm assuming you'd argue that the Servlet containers are doing it incorrectly as well, since we just retain the same behavior). It is almost entirely driven by your concern about performance due to executing path matching too often, correct? Les
