Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[Messenger] remove AllowNoHandlerMiddleware in favor of a constructor argument on HandleMessageMiddleware#28945

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged

Conversation

@nicolas-grekas
Copy link
Member

@nicolas-grekasnicolas-grekas commentedOct 22, 2018
edited
Loading

QA
Branch?4.2
Bug fix?no
New feature?no
BC breaks?yes
Deprecations?no
Tests pass?yes
Fixed tickets-
LicenseMIT
Doc PR-

AllowNoHandlerMiddleware adds a frame in the call stack but its concern should be handled byHandleMessageMiddleware to me, andHandlerLocatorInterface::getHandler() should not care about whether it's an error or not to not have a middleware (this makes it on par withSenderLocator in this regard.)

skalpa reacted with thumbs up emoji
@nicolas-grekasnicolas-grekas added this to the4.2 milestoneOct 22, 2018
@nicolas-grekasnicolas-grekasforce-pushed themessenger-allow-no-handler branch 2 times, most recently fromb8407df to5c6b0b6CompareOctober 22, 2018 13:11
returnarray($middleware);
->always()
->then(function ($middleware) {
return\is_string($middleware) || !\is_int(key($middleware)) ?array($middleware) :$middleware;
Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

(this borrows fromProcessor::normalizeConfig() and fixes a bug actually, same as whatfixXmlConfig() does, but when no plural form exists)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Should we put\is_string($middleware) || !\is_int(key($middleware)) insideifTrue() instead of usingalways()? Would be consistent with the rest of the nodes I guess.

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

makes sense, updated

$handler($envelope->getMessage());
$next($envelope);
}elseif (!$this->allowNoHandlers) {
thrownewNoHandlerForMessageException(sprintf('No handler for message "%s".',\get_class($envelope->getMessage())));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

will become$envelope->getDispatchKey() ?? \get_class($envelope->getMessage() right

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Correct, one PR or the other will need a rebase once merged.

@sroze
Copy link
Contributor

For the records, now, to allow no handlers on a given bus, here is the following configuration:

framework:messenger:buses:events:default_middleware:allow_no_handlers

@sroze
Copy link
Contributor

Thank you@nicolas-grekas.

@srozesroze merged commitaedb281 intosymfony:masterOct 25, 2018
sroze added a commit that referenced this pull requestOct 25, 2018
…f a constructor argument on HandleMessageMiddleware (nicolas-grekas)This PR was merged into the 4.2-dev branch.Discussion----------[Messenger] remove AllowNoHandlerMiddleware in favor of a constructor argument on HandleMessageMiddleware| Q             | A| ------------- | ---| Branch?       | 4.2| Bug fix?      | no| New feature?  | no| BC breaks?    | yes| Deprecations? | no| Tests pass?   | yes| Fixed tickets | -| License       | MIT| Doc PR        | -`AllowNoHandlerMiddleware` adds a frame in the call stack but its concern should be handled by `HandleMessageMiddleware` to me, and `HandlerLocatorInterface::getHandler()` should not care about whether it's an error or not to not have a middleware (this makes it on par with `SenderLocator` in this regard.)Commits-------aedb281 [Messenger] remove AllowNoHandlerMiddleware in favor of a constructor argument on HandleMessageMiddleware
@nicolas-grekasnicolas-grekas deleted the messenger-allow-no-handler branchOctober 25, 2018 09:41
nicolas-grekas added a commit that referenced this pull requestOct 25, 2018
…is empty, it will be `null` (sroze)This PR was merged into the 4.2-dev branch.Discussion----------[Messenger] If `framework.messenger.buses.X.middleware` is empty, it will be `null`| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | yes| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#28945| License       | MIT| Doc PR        | øOtherwise, it would fail with the following configuration:```yamlframework:    messenger:        buses:            events_bus:                middleware:#                    - 'some_commented_middleware'```Commits-------91a70fc If `framework.messenger.buses.X.middleware` is empty, it will be `null`
This was referencedNov 3, 2018
javiereguiluz added a commit to symfony/symfony-docs that referenced this pull requestDec 28, 2018
This PR was merged into the 4.2 branch.Discussion----------[Messenger] Fix allow_no_handlers for 4.2Fixes#10689 (comment)Ref:symfony/symfony#28945Commits-------ab2684e Fix allow_no_handers for 4.2
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@xabbuhxabbuhxabbuh left review comments

+3 more reviewers

@ro0NLro0NLro0NL left review comments

@skalpaskalpaskalpa requested changes

@srozesrozesroze approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

4.2

Development

Successfully merging this pull request may close these issues.

6 participants

@nicolas-grekas@sroze@ro0NL@xabbuh@skalpa@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp