IMHO the approach you mention sounds a little bit to complicated... I'll already have problems writing a simple documentation for the current implementation. As I mentioned the setter based injection will also take care of it automatically.
But as there are many other opportunities for improvement (e.g. suggested <default/> element, guard against double service injection) I think we can keep it in mind for later. --knut On Mon, 8 Nov 2004 13:27:55 -0300, Marcus Brito <[EMAIL PROTECTED]> wrote: > Yes, sounds reasonable. At first I was baffled by the "throw an error > if no constructor match" part, but then I realized it does makes > sense: this will occur only if the class doesn't have a constructor we > can satisfy, not even a default constructor. > > What about the service ID autowiring? Drop it completly? I still think > that the approach I mentioned in my previous message is valid (try to > match it only if we couldn't find a matching constructor without it). > > > > -- Marcus Brito <[EMAIL PROTECTED]> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
