Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

manually decorate the core JMS handler registry #1873

Merged
merged 1 commit into from
Feb 27, 2018

Conversation

xabbuh
Copy link
Member

@xabbuh xabbuh commented Feb 27, 2018

This works around the fact that custom handlers are processed in
JMSSerializerBundle after Symfony's DecoratorServicePass has been
executed (which means that we cannot use proper service decoration).

The old code still used to work on Symfony 2.x applications where
FOSRestBundle was registered after JMSSerializerBundle. In those cases,
custom handlers were processed before the handler registry was replaced
by the compiler pass coming from FOSRestBundle.

More recent Symfony applications have not been affected by this bug as
the compiler pass priority would have ensured the correct order in which
the passes would have been executed.

@XWB
Copy link
Member

XWB commented Feb 27, 2018

Nice find @xabbuh

Just one more test needs to be resolved:

FOS\RestBundle\Tests\Functional\DependencyInjectionTest::testSerializerRelatedServicesAreNotRemovedWhenJmsSerializerBundleIsEnabled
Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: The "test.jms_serializer.handler_registry" service or alias has been removed or inlined when the container was compiled. You should either make it public, or stop using the container directly and use dependency injection instead.

This works around the fact that custom handlers are processed in
JMSSerializerBundle after Symfony's DecoratorServicePass has been
executed (which means that we cannot use proper service decoration).

The old code still used to work on Symfony 2.x applications where
FOSRestBundle was registered after JMSSerializerBundle. In those cases,
custom handlers were processed before the handler registry was replaced
by the compiler pass coming from FOSRestBundle.

More recent Symfony applications have not been affected by this bug as
the compiler pass priority would have ensured the correct order in which
the passes would have been executed.
@xabbuh
Copy link
Member Author

xabbuh commented Feb 27, 2018

@XWB here we go 🎉

@XWB
Copy link
Member

XWB commented Feb 27, 2018

All green 🎉

@xabbuh xabbuh merged commit 17c8de8 into FriendsOfSymfony:master Feb 27, 2018
xabbuh added a commit that referenced this pull request Feb 27, 2018
This PR was merged into the 2.3-dev branch.

Discussion
----------

manually decorate the core JMS handler registry

This works around the fact that custom handlers are processed in
JMSSerializerBundle after Symfony's DecoratorServicePass has been
executed (which means that we cannot use proper service decoration).

The old code still used to work on Symfony 2.x applications where
FOSRestBundle was registered after JMSSerializerBundle. In those cases,
custom handlers were processed before the handler registry was replaced
by the compiler pass coming from FOSRestBundle.

More recent Symfony applications have not been affected by this bug as
the compiler pass priority would have ensured the correct order in which
the passes would have been executed.

Commits
-------

17c8de8 manually decorate the core JMS handler registry
@xabbuh xabbuh deleted the pr-1862 branch February 27, 2018 13:25
@Tobion
Copy link
Member

Tobion commented Mar 3, 2018

Does this fix #1851?

@xabbuh
Copy link
Member Author

xabbuh commented Mar 3, 2018

@Tobion yes, updating to 2.3.1 should help

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants