Hi Les, FWIW, after digging into this some more, it appears the problem of not calling init() on Initializable's is NOT a problem for Realm subclasses, but it IS a problem for Filter subclasses.
For example, org.apache.shiro.config.IniSecurityManagerFactory.createSecurityManager(Ini ini, Ini.Section mainSection) ensure Realms are init'ed by the call to IniSecurityManagerFactory.initRealms(securityManager) - which invokes Initializable.init(). However, Filter subclasses do not get init'ed. Only the org.apache.shiro.web.servlet.AbstractFilter.init(FilterConfig filterConfig) is called by a web server class (tomcat6: org.apache.catalina.core.ApplicationFilterConfig().getFilter():295). This call to AbstractFilter.init(FilterConfig filterConfig) results in a call to an init() method (however, this init() method is NOT an impl of Initializable, it is: "AbstractShiroFilter.init() throws Exception"). Also, only the single "uber" ShiroFilter instance gets this call from ....catalina.core.ApplicationFilterConfig().getFilter() (no Filter subclasses get this call). All this said, I'm not at all certain my Filter implementation is correct (and maybe much of my filter logic should either be moved to a Realm OR my filter should make use of the Servlet Filter delegate redesign I saw mentioned elsewhere -> a design change that would make it easier to reuse existing Tomcat filters as it - which is basically exactly what I am trying to do). I saw this, because the reason I needed the init() call was to make sure the FilterConfig info was available for the Servlet Filter instance I am delegating to. I guess such a redesign may still have need for this sort of "init()" event anyway.... Could you point me to the Servlet Filter Delegate changes? Are they only in trunk? Thanks, Dan -- View this message in context: http://shiro-user.582556.n2.nabble.com/AuthenticatingFilter-lifecycle-when-used-in-urls-tp7578146p7578216.html Sent from the Shiro User mailing list archive at Nabble.com.
