[Messenger] Allow to provide context in the Serializer class #26900
Comments
|
Making it Implement ContextAwareEncoder|DecoderInterface looks sensible to me. |
|
Yes, that's a good idea. Though, just two parameters (for the format and the serialization context) in the declaration of the service would be enough, nah? Alternatively we could have the parameter configured via the |
|
I don't see any restriction to configure a context in the configuration (so, under As an example: framework:
messenger:
transport:
serialize_message_with_type_in_headers:
enable_max_depth: true
groups: [messenger]
disable_type_enforcement: ~Or yes, just add a setter on the Serialize service, to inject a custom context. So we can configure in the service definition, or set (and change) at runtime, in a middleware for example (custom logic, adaptive to a message). |
|
I was just thinking about a parameter... so you'd configure it this way: parameters:
messenger.transport.default_serialization_context: {your: 'options'} |
|
This is actually a bug report, see #26935 |
|
Would make sense to add a messenger config option for this indeed. Another way (or complementary) would be to make it configurable at runtime by wrapping the original message into a context aware one. The same could be useful for some specific use-cases where middlewares might need to be configured at runtime for a specific message, e.g validation groups. |
|
How about in the existing |
|
Based on the fact that this transport is the default one and very likely to be the one used in 90%+ of the scenarios, I'd say it makes sense to be able to configure its options via the |
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 ------- 1a3f0bb [Messenger] Allow to configure the transport
|
Fixed by #26941 |
…ing (ogizanagi) This PR was squashed before being merged into the 4.1-dev branch (closes #26945). Discussion ---------- [Messenger] Support configuring messages when dispatching | Q | A | ------------- | --- | Branch? | master <!-- see below --> | Bug fix? | no | New feature? | yes <!-- 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? | see CI checks <!-- please add some, will be required by reviewers --> | Fixed tickets | N/A <!-- #-prefixed issue number(s), if any --> | License | MIT | Doc PR | todo For now, this is mainly a RFC to get your opinion on such a feature (so it misses proper tests). Supporting wrapped messages out-of-the-box would mainly allow to easily create middlewares that should act only or be configured differently for specific messages (by using wrappers instead of making messages implements specific interfaces and without requiring dedicated buses). For instance, I might want to track specific messages and expose metrics about it. The Symfony Serializer transport (relates to #26900) and Validator middleware serve as guinea pigs for sample purpose here. But despite message validation usually is simple as it matches one use-case and won't require specific validation groups in most cases, I still think it can be useful sometimes. Also there is the case of the [`AllValidator` which currently requires using a `GroupSequence`](#26477) as a workaround, but that could also be specified directly in message metadata instead. ## Latest updates PR updated to use a flat version of configurations instead of wrappers, using an `Envelope` wrapper and a list of envelope items. Usage: ```php $message = Envelope::wrap(new DummyMessage('Hello')) ->with(new SerializerConfiguration(array(ObjectNormalizer::GROUPS => array('foo')))) ->with(new ValidationConfiguration(array('foo', 'bar'))) ; ``` ~~By default, Messenger protagonists receive the original message. But each of them can opt-in to receive the envelope instead, by implementing `EnvelopeReaderInterface`. Then, they can read configurations from it and forward the original message or the envelope to another party.~~ Senders, encoders/decoders & receivers always get an `Envelope`. Middlewares & handlers always get a message. But middlewares can opt-in to receive the envelope instead, by implementing `EnvelopeReaderInterface`. Commits ------- 749054a [Messenger] Support configuring messages when dispatching
In the class
Symfony\Component\Messenger\Transport\Serialization, the methodencode($message): arrayserializes the message with an empty context option. It might be interesting to be able to provide some context options (from the configuration for example) instead of overloading all the class.The text was updated successfully, but these errors were encountered: