> 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]
