This PR was merged into the 4.1-dev branch.
Discussion
----------
[Messenger] Minor improvements and cleanup
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
- enable some of opcode optimizations
- add missing typehints
- cleanup
Commits
-------
d8cc7a4715 Minor improvements and cleanup
This PR was squashed before being merged into the 4.1-dev branch (closes#26816).
Discussion
----------
[Messenger][FrameworkBundle] Move collector, command into the component & minor tweaks
| Q | A
| ------------- | ---
| Branch? | master <!-- see below -->
| Bug fix? | no
| New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | N/A <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A
Some suggestions more aligned with most of the core practices, mainly:
- Move the command & collector to the component itself. They are not dependent of the Fwb in any way and are useful out of the fwb usage.
- Add an exception in FrameworkExtension if the `framework.messenger` key is enabled, but the component isn't installed.
Commits
-------
6aec62bad3 [FrameworkBundle] Minor messenger component tweaks
f9c9ca0514 [Messenger] Move data collector & command into the component
This PR was squashed before being merged into the 4.1-dev branch (closes#26685).
Discussion
----------
[Messenger] Add a `MessageHandlerInterface` (multiple messages + auto-configuration)
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ø
| License | MIT
| Doc PR | ø
Based on @chalasr's PR: https://github.com/symfony/symfony/pull/26672.
This reduces the hassle of registering handlers: it allows the auto-configuration with a new interface `HandlerInterface`. At the same time, it allows a handler to handle multiple messages.
Commits
-------
07e6bc73a3 [Messenger] Add a `MessageHandlerInterface` (multiple messages + auto-configuration)
This PR was merged into the 4.1-dev branch.
Discussion
----------
[Messenger] Make NoHandlerForMessageException a logic exception
| Q | A
| ------------- | ---
| Branch? | master <!-- see below -->
| Bug fix? | no
| New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | https://github.com/symfony/symfony/pull/26648#discussion_r178049882 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A <!-- required for new features -->
To me, a missing handler for a message is a program logic exception (or misconfiguration). Even if it's only detected at runtime here.
It's the same as `ServiceNotFoundException` which even is an `\InvalidArgumentException`. Could eventually also be the case here.
Commits
-------
0489bbd948 [Messenger] Make NoHandlerForMessageException a logic exception