-
Notifications
You must be signed in to change notification settings - Fork 693
jms/serializer 2.0 compatibility #1899
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
jms/serializer 2.0 compatibility #1899
Conversation
bf5ea97 to
dcf3fd8
Compare
751ac96 to
397080a
Compare
|
Tests failure is not related to this PR but to #1912 |
397080a to
3429bc5
Compare
|
I don't truly know jms internals so I can hardly review this, please tell me when you think it is ready to merge :) |
|
I just faced it today so I'll hope it will get released :) |
Faced what? few days ago a first beta has been released (https://www.goetas.com/blog/whats-new-in-jmsserializer-v20/) |
|
The current incompatibility between FOSRestBundle and JMSSerializerBundle 3.0 |
|
@magnetik The status of this PR is almost definitive, I do not expect major changes. If you want to try JMSSerializerBundle 3.0 with jms/serializer 2.0 (that is beta for now) you can use my fork. Something as: |
|
@GuilhemN I think that this should be merged when jms will enter in the release-candidate stage (in 3 weeks) |
|
Ok, no problem, I'll merge it ☺ |
ed74e10 to
2b3d35d
Compare
2b3d35d to
8201895
Compare
|
This is ready for review now! |
|
Not sure if that custom fos type handler makes sense. It should have huge performance impact. Is there a reason for it? |
This is because of the Exception controller, we wanted users to be able to overide exceptions rendering for each sub class. I didn't find a better and simpler alternative at the time at least. |
|
@GuilhemN I think the best approach is to keep this as it is and optimize the handler in a different PR. |
| if (null !== $handler) { | ||
| return $handler; | ||
| } | ||
| } while ($typeName = get_parent_class($typeName)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As this was used for the exception handler, will it make sense to limit this behavior only for classes extending Exception ?
Performance of this loop are really impacting serialization performance...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure we could do that indeed
|
👍 |
|
Excellent work everyone, do we know when this will be merged in? |
|
Thank you @goetas :) |
|
yay! |
|
Hey guys ! |
|
@mansartesteban make sure you have |
|
Oh ! It works ! Thank you very much <3 |
This PR was merged into the 2.3-dev branch. Discussion ---------- Drop jms/serializer <1.13 ~~`GraphNavigatorInterface` has been introduced in JMS Serializer v1.12.0. We should use `GraphNavigator` instead to maintain backward compatibility with v1.11.0 and lower.~~ #1899 breaks compatibility with `jms/serializer <1.13.0` by using: - `JMS\Serializer\GraphNavigatorInterface` (>=1.12) - `JMS\Serializer\Context::hasAttribute()` (>=1.13) - `JMS\Serializer\Context::getAttribute()` (>=1.13) However, it is still possible to install older version of `jms/serializer` together with FOSRestBundle. This PR fixes it by updating a `conflict` constraint. Commits ------- 535e366 drop jms/serializer <1.13.0
|
Can a release be tagged with this fix? Thanks. |
This introduces the changes for supporting the upcoming jms/serializer 2.0 release
Some changes in composer.json and travisci are will not be necessary when serializer v1.13 will be released