Luke Taylor wrote: > I agree that reusability is important but I'm not convinced that these > changes are justified on this basis, or that is just about balancing > reusability and ease of use. The use of constructor arguments is about > guaranteeing that objects can only be created with a specific state (the > dependencies required by their design) and providing a single point for > checking that state (the constructor). This is a design issue based on > the requirements as determined by the developer at the time they write > the class. As time goes on and different requirements become apparent > from forum posts and so on, compromises are made, access is provided to > state that was previously immutable or unreadable etc etc. The most > reusable code may provide no-arg constructors and getters and setters > for everything, but it is also the least stable. > +1
> To summarise, there may be situations where we *do* want to open things > up in this way for some classes, to provide extra extensibility, but I > don't think accommodating the inadequacies of plexus is sufficient > justification for a cross-the-board change. Could it not be argued that > the changes should be made to plexus rather than Acegi? > Acegi Security should not be changed to accommodate limitations in IoC containers. If Plexus cannot be modified to support the required behaviour, I would encourage the addition of wrapper objects within a third party project (whatever is needing to use Acegi Security with Plexus) to achieve the required integration. I would hope that ultimately the wrapper objects could be removed, when Plexus supports constructor injection. The other issue is that not using Spring for IoC will become a more pronounced issue as we move towards 1.1.0, because the namespaces feature in Spring 2.0 will be leveraged. As part of this most (if not all) classes will be refactored to use [full] constructor injection and end users will be encouraged to wire things up with Acegi Security XML rather than <beans> XML. This is partly to make things easier on users (XML verbosity and auto-completion), partly to give XML validation, but also to provide a level of indirection between the OO implementation approach and user configuration approach (thus giving us more flexibility to refactor the former without breaking the latter). Therefore, perhaps the easiest thing to do would be look at using Spring as an internal configuration subsystem for Acegi Security and simply wrapping the Spring IoC container inside a bean that is in turn registered with Plexus or any other IoC container for that matter. On another issue, could ask was there a technical reason Plexus was selected instead of Spring? Perhaps you could use namespaces with Spring in your project, as they do give you a lot of genuine benefits aside from simpler Acegi Security integration (as summarized above). Best regards Ben ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
