I have removed the default constructors added. On 7/17/06, Ben Alex <[EMAIL PROTECTED]> wrote: > 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).
The application already uses it. There's no poing on having two IoC containers, but due to Acegi hardcoded dependencies in Spring we'll still have to bundle the spring jars. It'd make lot more sense to have an acegi-spring module and remove all of the non core spring dependencies (exceptions and so) from acegi-core > > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Home: http://acegisecurity.org Acegisecurity-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
