Symfony framework serializer default_context not passed to JsonLd ItemNormalizer
API Platform version(s) affected: 3.x.x
Description
While investigating, why the property "__isCloning" from the doctrine entity proxy will always be normalized, I tried to ignore this attribute using the symfony framework configuration to provide a default context to the serializer.
The SerializerPass from the symfony serializer component has the task to pass the configured default context to all normalizers which are tagged with serializer.normalizer.
Currently, only one service with the id api_platform.serializer.normalizer.item has the required tag.
As a result, whenever another serializer, besides this one, is used, it is missing the configured default context.
This affects the JsonLd ItemNormalizer and properly all other normalizers provided by API Platform as well.
How to reproduce
- setup a symfony project containing API Platform
- add an API resource containing at least two properties
- configure
framework.serializer.default_contextwithignored_attributescontaining one of the two attributes of the API resource, for example - use the swagger UI to create one instance of the API resource
- introspect the response which is still containing the ignored attribute
- it is also possible to introspect the arguments of
\ApiPlatform\JsonApi\Serializer\ItemNormalizer::__constructto see that thedefaultContextarray is always empty
Possible Solution
Maybe tagging the other provided normalizer with the tag serializer.normalizer is enough to solve the issue.
Additional Context
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Could some maintainers please have a look, so this issue does not get lost?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue requires classification.
can you provide a patch?
@soyuka Since it is not clear to me why API Platform chose this implementation to serialize API Resources, I am not able to provide an actual patch for it.
My suggestion was a starting point for a possible solution but I am not sure if this might introduce unwanted side effects like the execution of serializers which should not be used in the end.
I was actually hoping that one of the core members who introduced the current concept would be able to take a look and determine if my suggestion could be harmful or not or better actually provide a fix for this issue.
It is also hard for me to actually construct a test case for this issue to ensure no other side effects are appearing.