I like where you are heading with this; I think HiveMind's constructor injection support is somewhat weak and doesn't have to be. I agree that th ebest solution is to throw out any ambiguous constructors, and start with the longest constructor ... but I think if that prooves difficult, you should down the list until some match is found.
On Mon, 8 Nov 2004 14:32:05 +0100, Knut Wannheden <[EMAIL PROTECTED]> wrote: > On Mon, 08 Nov 2004 13:55:26 +0100, Achim Huegen <[EMAIL PROTECTED]> wrote: > > > > Knut Wannheden wrote: > > > .. > > > - Should there be an attribute on <construct> to explicitly enable or > > > disable this constructor autowiring (e.g. "autowire-constructor")? > > > IMO the BuilderFactory should be default autowire the constructor if > > > there are no declared constructor parameters. This should work well > > > for both the setter based _and_ constructor based dependency injection > > > camps. > > > > I can imagine services where it is possible to use both constructor > > parameters and setters for configuration. To prevent double wiring it > > would be nice to switch off one type of autowiring. How about extending > > the autowire-services attribute to support yes/no/constructor/setter ? > > > > I can see that one would use constructor based injection to autowire > services and setter based injection for configurations, but in which > cases would one provide both constructor based and setter bases > injection for the same dependency? Can you provide an example? And > is there even a problem with double wiring? > > > > - Should BuilderFactory report an error if there are multiple > > > constructors which seem equally adequate (same number of parameters > > > and a matching service for each)? > > > > > > > Probably these constructors have never been designed for autowiring. > > So I would log a warning only. > > > > For constructor autowiring the BuilderFactory would only consider > those constructors where all parameters' types are interfaces > (including the common ClassResolver, ErrorHandler, ErrorLog, Log, and > Messages interfaces) or maybe String for injecting the service id. > Based on this there are a number of situations to deal with: > > - should the set of considered constructors be pruned by rejecting > constructors declaring multiple parameters of same type? > - what if there are multiple considered constructors with an equal > number of (but different) parameters? > - what if there is no service implementing the interface declared by a > constructor parameter? is this a constructor which wasn't designed for > constructor injection? > - what if there are multiple service implementations for a parameter > of the constructor? > > Hmm... > > --knut > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
