Hi Kalle, First let me say thanks for putting in the thought and time for your mail - I'm always excited to see people new to JSecurity take an interest and contribute their ideas back to the project.
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 :). Great! We're glad to help however we can. > 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. I've never used Acegi myself, but a few of the other JSecurity developers have. I can say I am extremely grateful for feedback from folks like you who know the landscape of both and can offer suggestions and improvements. We aim to be the best security framework out there, and that can't happen without community contributions - so, we're all ears :) > 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. I wholeheartedly agree. I wasn't terribly happy with my initial work on this as inheritance smelled funny after it was in place. I would like to clean this up significantly before 1.0. 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). Sure, I'm totally open to these types of suggestions. > 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. > > > Basically I'm polling your interest of accommodating internal change > requests. If you are already gearing up towards stable 1.0 release you might > not be interested or not have time for it, but if you welcome improvement > suggestions on internals of the framework, I'd be happy to work with you. We would absolutely appreciate your feedback and contributions - I think we're very much open to suggestions prior to 1.0, since it makes sense (at least to me) to get these kinds of additions in place before a 1.0 stable release. By far the biggest reason why we're in the ASF Incubator is to build and grow a healthy community around the project. I'm sure your experience with Acegi and other frameworks would be a welcome addition to our community. > While I can get this done either way (and not absolutely sure yet if > jsecurity will fullfill my needs) and I don't particularly care where the > code resides, I'm interested in getting the changes into jsecurity for > maintainability reasons. The less code I have in the integration module, the > more likely it is to continue working with newer versions of jsecurity > without changes. Let me know, and we can figure out the best way to interact > - I can open issues, create patches, let you guys browse the code of current > integration module or whatever else. The best way is to discuss your ideas and approaches on the dev list which will then probably lead to Jira issues and patches. With enough due diligence and open discussion, there is a very good possibility to become a committer - we're definitely open to others joining the project as committers assuming said due diligence. Just be aware that the ASF requires signing contributor agreements before that can happen ( http://www.apache.org/licenses/#clas). So, we definitely look forward to discussion and your ideas. Let loose :) Best regards, Les
