Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[DI] Allow autoconfiguring bindings #27806

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 8, 2018

Conversation

nicolas-grekas
Copy link
Member

@nicolas-grekas nicolas-grekas commented Jul 2, 2018

Q A
Branch? master
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets -
License MIT
Doc PR -

I've come up with a case where we will need to inject a different service based on which interfaces a consumer service implements: injecting a different token storage for monolog processor than for everything else. Required in #27801.

@weaverryan
Copy link
Member

Ah, so this basically allows a library to enable an optional "bind" based on an interface e.g. IF a user's service implements ProcessInterface, then "bind" any TokenStorageInterface arguments.

But, I don't understand the exact use you're describing. In #27801, you make it possible to configure the TokenProcessor with zero config (autoconfigure + autowiring will take care of everything). But then in this PR, you bind TokenStorageInterface to security.actual_token_storage... I'm not sure what difference that makes. And what is security.actual_token_storage?

@nicolas-grekas
Copy link
Member Author

nicolas-grekas commented Jul 3, 2018

bind TokenStorageInterface to security.actual_token_storage... I'm not sure what difference that makes. And what is security.actual_token_storage

The goal is to not trigger authentication by adding the user to the logs as this would defeat the very purpose of lazy authentication. security.actual_token_storage is the storage when the token is actually stored :) After ##27817, security.token_storage will be a wrapper around security.actual_token_storage that calls the authentication stack when getToken() is called. Here, we do not want to trigger this stack, so we get direct access to the storage backend, and if there is a token there we use it. If not we don't trigger the stack.

@nicolas-grekas nicolas-grekas force-pushed the autoconf-bindings branch 4 times, most recently from 23c6d5e to d632ee9 Compare July 8, 2018 09:04
@nicolas-grekas
Copy link
Member Author

I removed the unrelated bits, PR ready to vote+merge.

@nicolas-grekas nicolas-grekas merged commit 7c29977 into symfony:master Aug 8, 2018
nicolas-grekas added a commit that referenced this pull request Aug 8, 2018
This PR was merged into the 4.2-dev branch.

Discussion
----------

[DI] Allow autoconfiguring bindings

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

I've come up with a case where we will need to inject a different service based on which interfaces a consumer service implements: injecting a different token storage for monolog processor than for everything else. Required in #27801.

Commits
-------

7c29977 [DI] Allow autoconfiguring bindings
@nicolas-grekas nicolas-grekas deleted the autoconf-bindings branch August 8, 2018 08:43
@nicolas-grekas nicolas-grekas modified the milestones: next, 4.2 Nov 1, 2018
This was referenced Nov 3, 2018
nicolas-grekas added a commit that referenced this pull request Apr 7, 2019
…ults (przemyslaw-bogusz)

This PR was merged into the 4.3-dev branch.

Discussion
----------

[DI] Fix bad error message for unused bind under _defaults

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | yes
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #27828
| License       | MIT

**Sidenote**: I originally included the fix in #29897, but I decided to close the previous PR and divide it into two separate PRs for clarity.

**Description:**
With this fix, the message regarding an unused bind will have a clear information about the type of the bind (defined under __defaults_, __instanceof_ or _per service_), as well as the name of the file, in which it was configurated. It's for, both, YAML and XML configurations.

For the core team, please note, that the fix assumes a possibility of definings binds under __instanceof_, which was introduced in #27806. But since fixes are merged into other branches, I thought that it might be necessary to inlude this possibility. If this case requires making separate fixes for different branches, I will gladly do it.

Commits
-------

35bf420 [DI] Fix bad error message for unused bind under _defaults
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants