Thanks Les. Well, Tapestry might be the exception here, but *if* Ki would use composition rather than inheritance, I would be able to use the bind() and unbind() operations from the same class that KiFilter would delegate to, rather than copying the same code to my Tapestry specific Ki filter, which is what I current do. Tapestry doesn't use javax.servlet.Filter interface but implements its own org.apache.tastery5.services.HttpServletRequestFilter. For the same reason, I have to create wrappers around the existing authc, authz.. etc. Ki Filters so I can use them in my Tapestry application without having to re-write them for Tapestry. If Ki had its own SecurityFilter, or similar root interface, it'd make it easier to use Ki in web applications that do not use the Servlet interface. The default Ki implementations obviously could use inheritance to minimize overhead for maintaining wrapper objects.
Kalle PS. some links for the current, not-yet-released implementation: http://svn.codehaus.org/trails/trunk/tapestry-jsecurity/ http://svn.codehaus.org/trails/trunk/tapestry-jsecurity/src/main/java/org/trailsframework/security/services/JSecurityConfiguration.java On Fri, May 1, 2009 at 3:29 PM, Les Hazlewood <[email protected]> wrote: > I've recently started thinking again how to better resolve the issues Kalle > brings up in this previous thread: > http://markmail.org/thread/ofk6dfavjn7wlafo > > During my review of the code, it appears that our default WebConfiguration > implementation is really just an unnecessary abstraction away from a normal > Filter implementation. Because our implementation requires the > FilterConfig > object and then performs configuration steps based on FilterConfig values, > the code feels like the logic that exists in most filters, as if it should > just be in the KiFilter (or maybe an intermediate superclass) by default. > That is, our implementation is very filter specific, and a separate > instance > doesn't buy us much in this case. > > My question - does it make sense to just have the KiFilter (or an > intermediate superclass) do most of this stuff, and recommend integration > components just subclass it? (e.g. SpringKiFilter, TapestryKiFilter, etc)? > > Typically I favor Composition over Inheritance, but it seems as if > subclassing might make more sense here. Of course there could but > SpringWebConfiguration and TapestryWebConfiguration implementations instead > of subclassing the KiFilter, but if they have to work with FilterConfig > objects and other related concepts, why not just subclass KiFilter? Then > the one method in WebConfiguration would just be a protected method in the > KiFilter. > > Thoughts? > > Les >
