Point out aliasing object_constructor to doctrine_object_constructor not necessary

[drola]

After upgrading to the newest release of JMSSerializerBundle, Symfony started throwing

ServiceCircularReferenceException

Circular reference detected for service "jms_serializer.doctrine_object_constructor", path: "jms_serializer.doctrine_object_constructor -> jms_serializer.doctrine_object_constructor"

Upon investigation, I found out this was part of my configuration:

services:
    jms_serializer.object_constructor:
        alias: jms_serializer.doctrine_object_constructor
        public: false

It appears this snippet was necessary before introduction of DependencyInjection/Compiler/DoctrinePass.php. However, if I understand things correctly, it is not necessary to alias object_constructor to doctrine_object_constructor anymore. Is this correct? If so, it would be nice to update documentation in relation to this.

[hasc]

I am not able to configure a custom object constructor anymore that uses "jms_serializer.doctrine_object_constructor" as fallback (injected in the constructor).

This also throws a "ServiceCircularReferenceException".

[goetas]

I think that this is a unintentional BC break introduced with #803

To solve your issue you should use symfony decorators (https://symfony.com/doc/current/service_container/service_decoration.html) and decorate the jms_serializer.object_constructor service.

[goetas]

Would be great if you could add a note on the documentation mentioning this :)

[hasc]

think that this is a unintentional BC break introduced with #803

To solve your issue you should use symfony decorators (https://symfony.com/doc/current/service_container/service_decoration.html) and decorate the jms_serializer.object_constructor service.

I am struggling with this. I'd like to configure a custom constructor that uses the doctrine constructor as fallback. Would be great if you could show me how this can be achieved.

[bobvandevijver]

The change made in #803 was actually BC breaking in my case: the bundle started using a different object constructor by default, breaking my implementation.

[goetas]

@bobvandevijver i'm sorry for that...

[fastmanu]

had similar problem since we upgraded from

"jms/serializer": "3.7.0",
"jms/serializer-bundle": "3.6"

to

"jms/serializer": "3.10.0",
"jms/serializer-bundle": "3.7"

[DaedalusDev]

Hello,

Unfortunately, we faced the same BC. It would be nice to update the documentation at https://jmsyst.com/bundles/JMSSerializerBundle because many of the new features introduced in lastest versions are not referenced there.

As described by @goetas, we fixed our implementation using the decoration api.

services:
    jms_serializer.object_constructor:
        stack:
            - App\Service\CustomObjectConstructor: ['@doctrine', '@.inner']
            - JMS\Serializer\Construction\UnserializeObjectConstructor: ~

However, upon investigation, we found that the default constructor is now JMS\Serializer\Construction\DoctrineObjectConstructor when an ORM is injected into the config.

Our implementation is an override of the doctrine constructor, so we additionally disabled the default behavior to only use the fallback instance constructor UnserializeObjectConstructor.

jms_serializer:
    object_constructors:
        doctrine:
            enabled: false

Enjoy 🎉