> > > It is too soon to tell whether this is going to be an upgrade to > wicketstuff wicket-shiro or, given the scope of the changes, perhaps a new > project that supersedes it. Let me know if you have any thoughts or > suggestions on where we should take this. >
> Since there are people using wicketstuff shiro integration already, I > think it'd be nice to have a new major version of the shiro parts if > the changes will be large. This way the existing community has an > obvious upgrade path without causing confusion. If it is perceived > that there is more than one wicket-shiro project, it would probably > frustrate and/or fragment the community rather than help it. Les -- I agree with you, however the problem as we see it is that wicketstuff is not authoritative in any way. There are already multiple shiro/ki/jsecurity projects on there, most of which are not maintained in any way. It contains so many abandoned projects which scare off many developers. And the versioning and build process is mostly out of our control. What Matt, Ryan and I have discussed is potentially contributing the new and much cleaner integration to the shiro project itself, perhaps as a shiro-wicket submodule. I see there is a shiro-quartz integration, so we're hopeful this may be something the shiro devs would be open to. I'm convinced that shiro-wicket would be seen as authoritative and most devs wouldn't consider using the wicketstuff implementations. Is this a realistic goal, or would the shiro team object to something like this? Matt has been working on an initial implementation which we will be reviewing and then make available for shiro devs to review and comment. As far as an upgrade path is concerned, that is certainly an issue to consider. But the way the current wicket-shiro project is implemented could do with significant changes. One of the main goals is to utilize Shiro's annotations instead of the custom annotations in the project, which would mean a backward compatible upgrade-path would be more difficult. I suppose the custom annotations could just be deprecated wrappers for the shiro annots. But in many ways it might be best to do something clean from scratch and then update the wicket-shiro project with lots of references to the new shiro-wicket project. Fernando -- I too am a Wicket and Shiro user, but like you, I need to secure additional layers past the UI. My application has a RESTful API built with Jersey and Jackson. I'm also using Spring and tend to agree with Kalle that integrating Spring is worth doing. My suggestion would be to see about adding Spring into the mix and let it handle a lot of the AOP aspects for you. Tauren
