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.
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? The plexus web site also says on the main page that it supports "Various dependency injection techniques including constructor injection, setter injection, and private field injection." so I find that a bit confusing... Is the web site just plain wrong? Also, is plexus actually used in practice by anyone other than Maven? As I said before, we have deliberately moved towards the use of constructor injection for required dependencies, actually to avoid having to use Spring-specific constructs like the InitializingBean interface and to facilitate use outside of a Spring application context. Removing this will allow users to deploy misconfigured apps which will fail when first used rather than at deploy time, which I don't see as an improvement. What do other people think? I'm always interested in discussions about guaranteeing the state and integrity of objects and have come to see it as more of an important issue as time has passed. Luke Taylor wrote: > Opening this up to the list for discussion > > >> no problem >> I don't think it's just a plexus problem, in general it allows >> extensibility and reuse. For instance you may want to subclass it with >> a different behaviour and the constructor arguments approach is >> limiting. At the end it's a matter of balancing ease of use and >> reusability >> >> On 7/12/06, Luke Taylor wrote: >>> I think these kind of changes should be discussed on the list >>> beforehand. Ben and I talked about this kind of thing a while back and >>> agreed that enforcing initialization of objects with a particular state >>> and being able to guarantee their integrity isn't something to be given >>> up lightly. >>> >>> Do you mind if I forward your reply to the list. If we are going change >>> this approach to accommodate plexus then it should probably be discussed >>> there. >>> >>> Carlos Sanchez wrote: >>>> I'm adding Acegi to Continuum and it uses Plexus as IoC (it wasn't me) >>>> with the small problem that it doesn't accept constructor arguments. >>>> Default constructor+setters are still good to allow extension. I added >>>> javadocs to make clear the need of calling the setters later and >>>> checks to ensure the object is properly initilized. >>>> >>>> On 7/10/06, Luke Taylor wrote: >>>>> What's with adding all these default constructors? There was some >>>>> discussion a while back about using constructor injection for >>>>> initialization where possible for required dependencies and avoiding the >>>>> use of InitializingBean, setter injection etc... >>>>> >>>>> >>>>> > > > > -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523C http://www.monkeymachine.ltd.uk ------------------------------------------------------------------------- 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
