There are a couple of solutions to this problem. The first is to reload the filter invocation interceptor, and set the object definition source in it with an instance that holds the new values, like the following example:
Only here we have a trick that should be done. The bean objectDefinitionSource should be declared as non-singleton in the XML configuration, either by specifying its scope="prototype" or by specifying singleton="false". This solution has a problem, and it is that the whole list of roles and secure URL patterns will be reloaded from the database (or whatever your datasource is).
The other solution is to create your own ConfigAttributeDefinition that extends the one supplied by acegi. The main reason for doing this is that the one supplied by acegi doesn't have a removeAttribute method.I suggest overriding this implementation to add a removeAttribute method. I also prefer if you would use an ArrayList or a Map instead of the Vector used by the acegi implementation to represent the configAttributes
This ConfigAttributeDefinition should be the one you use in the UrlPatternDefinitionSource that we created in part one of this article.
In the class(es) that will be manipulating the the roles, you should inject the UrlPatternDefinitionSource instance that acegi creates (using spring's configuration files). You then get the ConfigAttributeDefinition for your role using the lookupAttribute method in the UrlPatternDefinitionSource class. A code snippet is shown below.
The previous code may need some optimization, but it was just to give you a general idea about how to implement dynamic role management.
I hope that this article was useful, and I apologize once more for the delay.