Skip to content
New issue

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

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

Already on GitHub? # to your account

Jersey 2: Relax ParamConverters constructor visibility to public #5791

Closed
Spikhalskiy opened this issue Nov 6, 2024 · 2 comments · Fixed by #5792
Closed

Jersey 2: Relax ParamConverters constructor visibility to public #5791

Spikhalskiy opened this issue Nov 6, 2024 · 2 comments · Fixed by #5792

Comments

@Spikhalskiy
Copy link
Contributor

Spikhalskiy commented Nov 6, 2024

PR #5349 changed the visibility of default ParamConverter constructors in Jersey 2.40+ to private. For example:
https://github.com/eclipse-ee4j/jersey/pull/5349/files#diff-739aa86c923eab6eead201b6b5da407758e6786b49473e9fd8507e0a172427c2R269

Our project extends default ParamConverters to handle custom encryption and correspondent annotations and 2.40 breaks this ability for us. The only workaround I see would be to copy-paste all the default implementations to our project, which I would love to avoid, or to use reflection to open up the constructors.

Looking at the PR, closing up the constructors doesn't seem to be the objective and this compatibility break is more of an unintended side effect. Constructors of OptionalCustomProvider and OptionalProvider are also left open, as the added fuature didn't touch them.

Could these constructors be opened up back and made public?

@Spikhalskiy Spikhalskiy changed the title Relax ParamConverters constructor visibility to public Jersey 2: Relax ParamConverters constructor visibility to public Nov 6, 2024
@senivam
Copy link
Contributor

senivam commented Nov 7, 2024

notice - it is not a good practice to rely on classes located in the **.internal.** or **.innate.** packages because they are subject to change without any prior notice or keeping of the backward compatibility.

@Spikhalskiy
Copy link
Contributor Author

Spikhalskiy commented Nov 7, 2024

Completely fair and we are ready to deal with changes in the internal packages. I’m not saying that the change in the PR is breaking a public API.

We still want to just slightly “decorate” the standard Jersey implantation instead of copy-pasting / reimplementing it.

So it would be nice to hear a take on making the constructors of these internal classes back open.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
2 participants