Thanks for the help. After thinking about it more, it's okay as-is, I just have to think about Shiro in a slightly different way than I was, which is probably more appropriate anyway. Most of that is my being used to rolling my own authc/authz code using Servlets, so thinking about security as a Filter required a couple of days to sink in, and morphing my LoginServlet into a LoginFilter brought with it some application initialization baggage that really could have been elsewhere.
The one thing that I still think is strange, though, is that my onFilterConfigSet() method was never called, even though nowhere in the inheritance of my class was that method declared final, and it comes from a non-final version in AbstractFilter. Instead, the final onFilterConfigSet method in ShiroFilter was called, even though my filter doesn't inherit from there. As you know, ShiroFilter also inherits from AbstractFilter, but down a different inheritance tree. Now that I know this is the way it works I can avoid depending on this method, however I'd by lying if I said I understood why that is, and the Javadoc for AuthenticatingFilter implies that I should be able to override that method in my subclass. I suppose I also could have called it specifically in my init() method, similar to how AbstractFilter does, but it's better the way I have it now. Like I said, though, it turns out for what I needed I didn't need to do this at all, and just baked the data access that I needed into the destination servlet, which ultimately makes more sense anyway. Thanks again for the help. -- View this message in context: http://shiro-user.582556.n2.nabble.com/Can-t-get-ServletContext-from-Filter-tp7468957p7475188.html Sent from the Shiro User mailing list archive at Nabble.com.
