Repository navigation
Conversation
Closes: keycloak#54599 Signed-off-by: Peter Zaoral <pzaoral@redhat.com>
|
@shawkins the direction that Quarkus goes is clear, at least for the server-side, so I count with the deprecation (though I'm not sure whether it was properly discussed somewhere, at least not here on Github). For keycloak-admin-client side, we probably don't need to deprecate anything and leave as is (with an exception of keycloak/keycloak-client#253). |
It should be mentioned somewhere though as custom endpoint logic could be affected correct?
Why? Wouldn't it be best to keep Jackson 2 as a legacy concern? |
Definitely... It's a breaking change. It would be good to make it part of this PR, or a follow-up. |
There was a problem hiding this comment.
It 8000 might be worth double checking if we need this compatibility layer, if we can't just migrate to Jackson 3.
That's what I meant - to keep both, without deprecating Jackson 2. Currently we have both admin client variants in the repo, side by side, therefore I said I would keep as is. |
|
I'm proposing to make the representation changes with #54909 and add a note which may eventually be subsumed by the switch to Jackson 3. |
Closes: #54599
Here I decided to move the existing Jackson 3 representation adapters into a shared module and use them in both the admin client and server. I also kept their mapper settings separate and preserved compatibility existing Jackson 2 JSON tree values and mapper consumers.
Note: keycloak/keycloak-client#253 also requires matching source-sync changes.