I dont know how close the relationship is between your team and the acegi developers but it seems that one area where the standard acegi classes fall a little short is in assigning security contexts to methods and URLs (it seems that the current default implementation uses a fairly obscure regex style to map methods calls and urls to roles). As I said, I am unsure of how much influence you have over the acegi development, but it would be interesting to see an alternative method where roles were assigned to resources using AOP wrappers around target beans (for method invocation security) and around the actually controller 'modules' (for web based URL security).Something to consider perhaps?Once again, thanks for the work you have put into Spring.
The Acegi Security framework for Spring was mostly written by somebody called Ben Alex. I'm the only Spring developer who's also an Acegi Security Framework committer, and we all have a good relationship with Ben, but he is responsible for probably 95% of the Acegi lib.
You'll have to clarifly what you mean by using AOP wrappers to assign roles to resources. Of course, AOP wrappers are _used_ to enforce method security, but the regex mechanism you mention is simply a form of pointcut to specify where the security interceptor should apply, e.g.
<bean id="bankManagerSecurity" class="net.sf.acegisecurity.intercept.method.MethodSecurityInterceptor">
From an example security interdeptor. Given that this interceptor can ultimately be applied to any object, this is actually a fairly clear and concise mechanism to specify what classes and methods to apply the role checks on.
All of the Acegi framework is built in an IOC style, so it's completely pluggable, including the source of the information as to what roles are required for what objects and methods. (These pluggable sources are in fact pretty similar to how the Spring transaction interceptors work). You could of course have an implementation which reads required security role information from JDK 1.5 annotations (or an alternative like commons-attributes). Whether it'd be appropriate to tie that information so closely to the java class being affected probably depends on the scenario. Personally most of the time I wouldn't want to do that, as the class shouldn't care.
With the AspectJ integration that is available now, I could see AspectJ notation being used to specify where an Acegi based security interceptor should apply. Given the tool support for AspectJ, there are probably some nice potential benefits to this approach, in terms of being able to manipulate these pointcuts in your IDE. There are of course some disadvantages too, such as the fact that the AspectJ compiler now has to be used.
If you've got some ideas, I encourage you to sign up to the acegisecurity-developer mailing list, and send them in. Ben is extremely responsive.