Agreed, String is probably to common to be used for autowiring. There
is after all still the possibility to declare a setter for a
"serviceId" property which will be autowired.
A detailed outline of the constructor autowiring strategy (which will
be employed iff "autowire-services" is "true" _and_ there are no
specified constructor parameters):
1. Gather all constructors which should be considered for autowiring.
This includes all constructors where all parameter types are
interfaces and none of the parameter types appears more than once.
Note that this also includes the default constructor.
2. Order the considered constructors by length (given by number of parameters).
3. Iterate through the ordered list of constructors
3.1 Match common parameter types (excluding String) as with current
autowiring and interfaces with registered service implementation.
a) For one or more service parameters there is no registered
implementation: Ignore silently and try next constructor (3).
b) For one or more service parameters there is more than one
registered service implementation: Log a warning and try next
constructor (3).
c) All parameters can be matched: Break (4).
4. Instantiate implementation using found constructor. Throw
ApplicationRuntimeException if this fails or no constructor was found.
Sounds reasonable?
Note that setter based injection will occur regardless of whether
constructor based injection was employed or not. It solely depends on
the "autowire-services" property.
--knut
On Mon, 8 Nov 2004 10:26:42 -0300, Marcus Brito <[EMAIL PROTECTED]> wrote:
> > Also for constructor autowiring I think that BuilderFactory should
> > wire parameters of type ClassResolver, ErrorHandler, ErrorLog, Log,
> > and Messages automatically as with the setter based injection. The
> > difference being that with constructor based injection there is no
> > name to these properties. I think maybe it should even inject the
> > service id if there is a String parameter.
>
> Agreed about the common interfaces autowiring, but I'm not so sure
> about wiring the service ID if there's a string parameter. At least,
> we should not treat it in the same way as the other properties.
>
> I can think of two distinct scenarios: new code and legacy code. For
> new code (where the decision to use hivemind has been taken before the
> code was written), I believe the developers will take care to write
> "compatible" constructors, and autowiring the service ID is handy
> here.
>
> For legacy code, this may be a bit too much -- String is a way too
> common class for us to assume that this will be the service ID. I
> would say that the service ID shouldn't be considered for constructor
> matching (i.e, the autowirer will look for the constructor without
> it), and will be wired if the only way to match a constructor is
> considering it. Something like this:
>
> BlackOperation(Assassin ocelot, Spy snake) { ... }
> BlackOperation(Assassin ocelot, Spy snake, String codeName) { ... }
>
> If there are registered Assassin and Spy services, the first
> constructor would be matched, and the service ID won't be wired. Now,
> if the only way to match a constructor is including the service
> property (let's say the first constructor didn't exist) then yes, the
> service ID will be used to match the constructor and autowired.
>
> The only gotcha is simplicity: all this constructor matching magic may
> be a bit over the top. If many people find this is the case (ah,
> feedback), I would say that the service ID shouldn't be matched at
> all.
>
> > If the user wants to call the no-arg constructor I think he will have
> > to set "autowire-services" to false. Note that if the no-arg
> > constructor is the only constructor considered for autowiring he
> > doesn't have a problem. And in the case there are others he will
> > probably disable autowiring anyways, otherwise his implementation is a
> > mix of constructor based and setter based injection.
>
> Again using the argument of legacy code, I could picture a scenario
> where the user doesn't want to autowire constructor arguments, but
> autowire properties. Anyway, I agree with you here:
> "autowire-services" should suffice to enable/disable autowiring, and
> we would be sacrificing the flexibiity to separately toggle
> constructor and property autoring for consistency and simplicity,
> which sounds like a good compromise.
>
> P.S.: sorry for replying the previous message in private. I'm starting
> to really hate this Reply-To bug in gmail/mailman.
>
> -- 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]
