Also you need to modifyhttps://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/Tests/DependencyInjection/ConfigurationTest.php#L298 as well ashttps://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/Tests/DependencyInjection/FrameworkExtensionTest.php#L663.

Given the issues we currently face in the Security component related to PHP'sserialize() implementation (see for example#29951) I am not sure if we should actively support this.

#29951 is about the Serializable interface and parent::serialize(). We should activity discourage using it (the method call but also the interface) anywhere BTW.

I haven't used this component, but as an outsider, compatibility with third-party systems look like a huge and important feature to me. Are you sure it's OK to make us incompatible with anything not related to PHP?

Somewhat related: for the future, we could consider using Google's Protobuf, which is what most cool and modern apps use nowadays (https://developers.google.com/protocol-buffers/docs/reference/php-generated).

Both your points are about the serializer doing a bad job with DTOs. Why not improve the Serializer to support DTOs better instead, it fixes this problem by proxy, but also improves the other component.

In my opinion we should support both out of the box, and indeed default to PHP'sserialize().@weaverryan's arguments make sense, but only when the consumer is written in PHP. It often makes sense to use other languages for async consumers (Go or C for computations, Python for Machine Learning...), in such cases consuming JSON is easier than parsing the PHP internal format.

Protobuf is also very interesting for this kind of use cases (but is not as popular than JSON). We could support both.

@dkarlovi we need to improve DTO support indeed (even if it has already been dramatically improved in 4.1/4.2), but it's not always the right tool anyway for messenger:serialize preserves private and protected states. It makes no senses to add this kind of features to the Symfony serializer (its goal is to transform the object in apublic representation).

I agree that using the Serializer Component makes has some drawbacks compared to usingserialize. On the other hand, it ensures that developers can choose a different serialisation method depending on their environment.

I also agree with@dunglas that the only useful way to fix this is to make it configurable: Symfony has always encouraged a pluggable system where you could easily modify the system to your specific needs while providing a sensible default setup. I believe that's what should be done here: allow using any serialiser but default to one using PHPs built-in serialisation functionality.

@dunglas don't really understand: the message in Messenger contextis in its public context.

@dkarlovi not really:

• private states are preserved when using synchronous handlers
• they aren't when a transport is configured

It hurts DX (especially for those used to how Laravel works). Messaging could be considered internal (as done when using a sync handler) from an app level. The serialization is just an implementation detail, and so preserving states would improve both DX and performance (it just works).

I would say that it's different if the message is intended to the current app (like when using a messenger handler) => private, or for another app (like one written in another language) => public.

especially for those used to how Laravel works

no need to write this. I've no idea what Laravel is, yet I spent an afternoon debugging that transport thing until I created#29163. We have a serious issue here.

The serialization mechanism is already "pluggable", here we're talking about changing the default.
I don't remember if we have a DI config integration to leverage this pluggability?

@nicolas-grekas I mean when you use Enqueue (it's the use case described by@weaverryan in the PR description), messaging is considered something purely internal and transparent. You don't even have to know that the message is serialized. It's "magic", but it works. When switching to Messenger, you have to think about using public properties, because JSON.

Seems it's time to revisit this convention of serializer and think about adding possibility to serialize such props as well

It's easy to do (as showcased by the code you linked).

they don't use native serialization

But why? native serialization is faster, and easy to use.

I would say that it's different if the message is intended to the current app (like when using a messenger handler) => private, or for another app (like one written in another language) => public.

It depends how you define "private", I guess. From Messenger's POV, the message passed is definitely in itspublic representation since it's going out of the local app's context onto a transport, it's irrelevant if the consumer is the same app again, that will be determined longafter you've already serialized it.

I don't remember if we have a DI config integration to leverage this pluggability?

We have such kind of configs in other components at least. Could be something like:

messenger:# ...serialize:private# default, can also be public (JSON) or a service name

We have such kind of configs in other components at least. Could be something like:

messenger:# ...serialize:private (default)# can also be public (JSON) or a service name

I agree with this point and instead of private/public I'd suggestnative|{service_id}, referring to services sounds like the best IMO

I don't remember if we have a DI config integration to leverage this pluggability?

the answer is yes, I just needed to look at the first file in the PR :)
There is nothing else to do here, by default we consider messages "private/internal", which we should.
And ppl who need interop with third-party apps have more work to do.
That's how things should be IMHO.

And ppl who need interop with third-party apps have more work to do.

This will probably continue to be debated, we might need "stats" about what proportion of apps use or don't use 3rd-party apps 😕

Let's agree the DX is seriously broken, up to the point where advocating the component to the masses is questionable currently.

This PR is a serious solution to the problem.
The Serializer component is really nice when compat with other techno is needed.
But that comes AFTER.

Oh, one last thing:
Symfony\Component\Messenger\Transport\Serialization\Serializer::create() should return that new serializer, isn't it? Maybe not actually, can anyone confirm?

I think no, because that's a factory to literally create an instance of THAT class. So, it should continue to create an instance of itself. However, there were 4 places in the code that used this factory function to create a default serializer if none was passed. I change those to create the newPhpSerializer. I think we should consistently use the same default serializer everywhere.

Thank you@weaverryan.

Hello,

I have framework.yaml

    messenger:        serializer:            id: 'native_php_serializer'

but get error

In ArrayNode.php line 331:                                                                                                                                        Unrecognized option "id" under "framework.messenger.serializer". Available options are "default_serializer", "symfony_serializer".

What should I fix in my config? Thanks

This should work (assuming thatnative_php_serializer is the id of a service that you defined):

framework:messenger:serializer:default_serializer:'native_php_serializer'

@xabbuh I was thinking it should be defined somewhere in component?

Now I have something else

Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: The service "enqueue.messenger_transport.factory" has a dependency on a non-existent service "messenger.transport.serializer".

I could not find any docs about it :(

I guess you can best use one of thesupport channels to get help setting things up properly.

@weaverryan
There is a bug (probably) in blog post about this feature:
https://symfony.com/blog/new-in-symfony-4-3-native-php-serialization-for-messenger

It should bedefault_serializer: instead ofid:

@mtomala when you and@weaverryan decide if this is a bug or not ... please ping me so I can update the blog post. Thanks.

At the time when this feature was added#29958 it was stillid now it isdefault_serializer

@javiereguiluz: Since#30628, the serializer to use is actually configurable per transport.

Themessenger.serializer section remains to configure both native (default) and symfony serializers:

but each transport can specify themessenger.transport.[name].serializer option to specify the service id to use.

(default is used otherwise)

Note doc is up-to-date:https://symfony.com/doc/current/messenger.html#serializing-messages