Just want to add some more options here which I mentioned on the
respective pull requests already:
5) Disabling interface injection on a per-method basis:
foo:
disable_interface_injection:
setContainer: true
6) Prepending calls from interface injection instead of appending them
7) Making it easier to disable interface injection globally
$passConfig->disableInterfaceInjectionPass()
IMO 6) is easiest to implement, and is consistent with what we already
do for definition inheritance.
Johannes
On Apr 14, 12:03 am, Lukas Kahwe Smith <[email protected]> wrote:
> Aloha,
>
> Whenhttps://github.com/symfony/symfony/pull/535was merged I noticed that this
> was causing issues when I tried to set an alternative service container,
> because ContainerAwareInterface implementing classes would now get the
> service container injected after my custom service container, effectively
> overwriting my customer container.
>
> I created a quick fix which was reverted for good reasons.
>
> I have created two additional pulls which in my opinion fix the issue, which
> is being able to override interface injection on a per service basis:
>
> 1)https://github.com/symfony/symfony/pull/544
> This pull effectively disables interface injection whenever a service has any
> explicit call's configured.
>
> liip_hello.phpcr.controller:
> class: Liip\HelloBundle\Controller\PHPCRController
> calls:
> - ['setContainer', [ @liip_hello.container ] ]
>
> 2)https://github.com/symfony/symfony/pull/547
> This pull adds a new flag to determine if interface injection should be
> disabled for this service
>
> liip_hello.phpcr.controller:
> class: Liip\HelloBundle\Controller\PHPCRController
> interfaceInjectionEnabled: false
> calls:
> - ['setContainer', [ @liip_hello.container ] ]
>
> Another approach would be to stop using interface injection in core entirely.
> However I think the same issues will then be caused by 3rd party bundles. I
> think the end user defining a service should always have final control over
> what gets injected. For the same reason we do not inherit stuff like tags's
> which cannot be removed in a service definition.
>
> 3) Now Johannes does not seem to like either of the proposed solutions. He
> indicated on IRC that he would prefer a more granular solution, where there
> would be an optional flag on a per method basis for disabling interface
> injection.
>
> I could it would look like something like the following, where the third
> element in the array would define that no "setContainer" calls should be
> added via interface injection.
>
> liip_hello.phpcr.controller:
> class: Liip\HelloBundle\Controller\PHPCRController
> calls:
> - ['setContainer', [ @liip_hello.container ], true ]
>
> 4) Jeremy was suggesting a setting that would determine some conflict
> resolution
> strategyhttps://github.com/symfony/symfony/pull/544#issuecomment-995402
>
> Personally I think that interface injection is nice syntax sugar, but its not
> critical to have. However it should definitely not get in the way of defining
> a service with custom dependencies. Of course I can always change the code to
> not implement the interface, but that kinda perverts the entire idea of
> dependency injection. So I think its critical that we fix the current
> situation.
>
> regards,
> Lukas Kahwe Smith
> [email protected]
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
