Make Acegi more CDI-friendly ?

[greg_greg]

Hi,

In an attempt to integrate Acegi in a Picocontainer-based application, I've been having the following possibilities:
* Use setter injection : this is made possible through pico's SetterInjectionComponentAdapter. Is a pita to setup, but works.
* Writing sub classes of the components I use with constructors taking their necessary/mandatory components as dependencies: works well, but might require many new "wrapper" class writing in any less-than-trivial setup.

However, I've been facing one problem, which is more configuration-related: some of the acegi components have dependencies on both other components AND configuration parameters; the AuthenticationProcessingFilter being of them, as it requires both an AuthenticationManager (component) and configuration parameters like authenticationFailureUrl, defaultTargetUrl, etc.

While this is in any case workable, I would tend to find it much easier to move all these config parameters into one simple javabean, like for instance
public class AcegiConfig implements Serializable {
private String loginFormUrl;
private boolean forceHttps = false;
private String authenticationFailureUrl;
private String defaultTargetUrl;
// and so forth ...
// getters and setters ...
}

... which could then be very simply injected into any other component that need any kind of configuration.

This would probably also make people like Craig Walls happy, by simplifying even more the reusage of acegi configurations accross projects (http://jroller.com/page/habuma/20041..._configuration)

Please tell me what you think. I could possibly provide patches for this if you like the idea.


Besides, I also wanted to advocate a bit in favor of Constructor Dependency Injection (which I believe is also usable with Spring), as I've found that some classes of acegi would shrink dramatically and be more readable by
a) exposing a constructor will all mandatory components
b) exposing b constructor will all mandatory and optional components
c) no need to write boring check methods like in afterPropertiesSet(), since you can't instanciate your component without having its mandatory dependencies set.

Well, I don't want to launch a debate on this anyways, as there are surely advantages to SDI which I've overlooked.

Ha, one last thing, for Ben: I've seen you've asked to some people saying they wanted to use Acegi in pico, why they wouldn't use Spring, if only just for Acegi... My answer to that would be that my whole application's wired by pico already, and that includes a couple of DAOs wired to hibernate, wired to datasources, .. which I intend to reuse as AuthenticationProviders.

Cheers, and many thanks for the excellent work on acegi !

[Ben Alex]

I don't favour moving to a single configuration bean, as it would defeat the encapsulation benefits. However, I am in favour of using more constructor injection for mandatory properties. Newer code in Acegi Security has been performing checks in the setters rather than InitializingBean, together with using sensible defaults in most cases.

One issue affecting refactoring at this stage is we're trying to get 1.0.0 RC1 out the door. It also means we cannot entertain changing configuration parameters until 1.1.0 at least, due to our use of the Apache APR Project versioning guidelines for release numbering.

I would welcome contributions you may wish to make. JIRA is the best place for these, with possible acegisecurity-developer discussion in the first instance if a change seems major or would disrupt many people.