Below is an excerpt of my previous email to the user list on the motivation for refactoring WebConfiguration & IniWebConfiguration. To better support configuring JSecurity in all-Java (without ini files that is), I'd like to add super, possibly abstract implementation of WebConfiguration that IniWebConfiguration would inherit from (rather than simply extend the interface). Also, I'd like to add SecurityFilterChain class to carry path-specific filter config information that this base implmentation of WebConfiguration would use. The refactoring would roughly follow the prototype implementation I made for Trails project ( http://www.trailsframework.org) for integration with jsecurity, see http://svn.codehaus.org/trails/trunk/trails-jsecurity/src/main/java/org/trailsframework/security/services/SecurityConfigurationImpl.javaand http://svn.codehaus.org/trails/trunk/trails-jsecurity/src/main/java/org/trailsframework/security/services/SecurityFilterChain.java. I'd need to touch several classes but I'd keep the public interfaces the same if at all possible. Does anybody see issue with what I'm proposing, and if not, should I just add it in one single JIRA and patch (and hopefully get somebody to look over it)? I could of course make several patches and refactor it little by litte, but I'm afraid it'd difficult to see the goal if the changes are broken into several patches. What say you?
Kalle On Tue, Feb 17, 2009 at 11:03 AM, Kalle Korhonen <[email protected] > wrote: > Hello jsecurity devs, > > I'm working on an initial integration of jsecurity with Tapestry5 as a > proof of concept. I'm especially keen on your flexible, built-in support for > instance-based security. With a considerable amount of hammering, I > implemented instance-based security for previous version of Trails framework > (which I'm a committer of) using Acegi (see for example > http://trailsframework.org/Security+module) and now I'm back for more :). > I've been an Acegi/Spring user for years but in an effort to reduce the > clutter and the "weight of history", I'm trying to remove dependencies to > them. Also, Acegi committers are very reluctant to change the existing > implementation even when it would make perfect sense (e.g. > http://jira.springframework.org/browse/SEC-517). As a first cut, I've > implemented basic url-based configuration and permission for Tapestry5 using > JSecurity. However, it wasn't quite as simple as I would have hoped for. > From my perspective, a little bit of refactoring would make your framework > better suited for many different cases. For instance it'd be so much nicer > if IniWebConfiguration would use composition for the ini files rather rather > than inheritance. Right now, I either need to inherit from > IniWebConfiguration (my Tapestry integration doesn't use the ini) and accept > lots of unnecessary operations or copy and paste several operations. > Similarly, it'd be much nicer if you custom types such as > SecurityFilterChain rather List<Filter> so it's extensible and can carry > more information (such as path-specific filter config). Finally, there's a > few places where you are doing new Object() & setObject() within the same > operation, again making it more difficult to extend the framework and > specifically for applying dependency injection. I'm not suggesting any > changes specifically for Tapestry integration. >
