This PR was squashed before being merged into the 4.1-dev branch (closes#26941).
Discussion
----------
[Messenger] Allow to configure the transport
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | ish
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #26900, #26908, #26935
| License | MIT
| Doc PR | ø
We allow users to configure the encoder/decoder used by the built-in adapter(s). This also adds the support of configuring the default's encoder/decoder format and context.
Commits
-------
1a3f0bbb14 [Messenger] Allow to configure the transport
This PR was squashed before being merged into the 4.1-dev branch (closes#26909).
Discussion
----------
[Messenger][DX] Uses the adapter name instead of the service name
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ø
| License | MIT
| Doc PR | ø
As a developer, I don't get why I would need to use the service name while I give a name to the adapters. This is basically what this PR means for me in terms of configuration:
```patch
framework:
messenger:
routing:
# We want the command below to be handled async with the "messenger.default_sender" (AMQP producer).
- 'App\Message\Command\CreateNumber': messenger.sender.amqp
+ 'App\Message\Command\CreateNumber': amqp
adapters:
amqp: "%env(AMQP_DSN)%"
```
And in terms of pulling the messages:
```patch
- bin/console messenger:consume-messages messenger.receiver.amqp
+ bin/console messenger:consume-messages amqp
```
Commits
-------
b5afb40441 [Messenger][DX] Uses the adapter name instead of the service name
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
