I had found this issue when I was writing the multiconf thing half a year ago. I don't quite remember how the reasoning was, but I had been thinking quite a lot about the conceptual thing and at the very least it passed all tests. It might be possible that this thing also needed the change for the multiconf thing, but I don't remember, especially not right now since my brain is fried from swimming too much.
On Tue, 19 Jul 2011 13:36:58 -0700, Howard Lewis Ship <[email protected]> wrote: > I'm actually not sure; I suppose we could switch it around to use the > passed-in ObjectLocator and run the tests to see what happens ... I > suspect the only difference would occur if a field had the @Local > annotation on it (though I'm not sure if it would be ignored, or > simply give odd results). > > Injection gets tricky with services and configuration objects that > themselves help implement injection (or, more specifically, object > resolution for dependency injection). > > On Tue, Jul 19, 2011 at 6:58 AM, Tom van Dijk <[email protected]> wrote: >> Hi! >> >> The two injection providers DefaultInjectionProvider and >> ServiceInjectionProvider both use services (ObjectLocator and >> MasterObjectProvider) provided at construction time rather than the >> object >> locator provided as a parameter to the provideInjection call. >> >> Is this correct behavior? >> >> Tom. >> >> --------------------------------------------------------------------- >> 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]
