I agree, this is probably the best way to go, but I would go about it a slightly different way. Here is what I believe to be the optimal way of the world when starting up web apps (this is how Shiro 1.2 works now too):
Create a ServletContextListener that performs all necessary initialization for your app and place something in the ServletContext that allows you to get access to necessary things at runtime. Application environment initialization is a separate concern from filtering requests, so ideally this wouldn't be tightly coupled to Filter initialization IMO. For example, in Shiro 1.1 and earlier, the entire Shiro environment was initialized when the main ShiroFilter was initialized. Because initialization was tightly coupled to Filter logic, any component that _wasn't_ a filter often couldn't get access to things they needed. Now Shiro init and filtering are nicely decoupled in Shiro 1.2: a new ServletContextListener (the org.apache.shiro.web.env.EnvironmentLoaderListener) initializes Shiro at app startup and places an Environment object in the ServletContext to ensure it is available should anything need it. The ShiroFilter then references the Shiro Environment object when it needs access to things during filtering. Any other application object also now has access to the Environment object should it need it, even if that component isn't a Filter or even Shiro-related. I consider this to be a best practice, even if Shiro wasn't involved. You could leverage the same benefits in your own app. I should also note that this is exactly how Spring web-apps work as well (Shiro's implementation was based on ideas behind Spring's ContextLoaderListener), so if you don't want to reinvent the wheel for your own app, you might want to try it if you're not using it already. I'm sure Guice has a similar concept as well. Finally, with regards to Filter config, I would also like to reiterate the power of Shiro's filter chains: they can be configured with _any_ javax.servlet.Filter, not just Shiro-specific ones. In my opinion, the best thing to do is to configure all of your filters (non Shiro filters too) in the Shiro [main] section if possible, and reference them in the [urls] section. Shiro's INI (and other config formats that may be used like Spring or Guice) are more convenient than web.xml and much easier to understand what chains look like instead of interpreting locations in web.xml. HTH, -- Les Hazlewood CTO, Katasoft | http://www.katasoft.com | 888.391.5282 twitter: @lhazlewood | http://twitter.com/lhazlewood katasoft blog: http://www.katasoft.com/blogs/lhazlewood personal blog: http://leshazlewood.com
