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

Make resolution algorithm of ConnectionDetailsFactory more explicit #39737

Closed
wants to merge 1 commit into from

Conversation

snicoll
Copy link
Member

@snicoll snicoll commented Feb 23, 2024

This commit moves the resolution check for ConnectionDetailsFactory to a dedicated method to make it more clear that it is meant to verify that the implementation is resolved and can be loaded from the classpath.

The previous algorithm relied on a behavior of ResolvableType that only resolves the first level generics. Further improvements in Spring Framework 6.2 make this check invalid as some implementations use a Container that can hold a nested generic.

@snicoll snicoll added the status: waiting-for-triage An issue we've not yet triaged label Feb 23, 2024
This commit moves the resolution check for ConnectionDetailsFactory
to a dedicated method to make it more clear that it is meant to verify
that the implementation is resolved and can be loaded from the
classpath.

The previous algorithm relied on a behavior of ResolvableType that only
resolves the first level generics. Further improvements in Spring
Framework 6.2 make this check invalid as some implementations use a
Container that can hold a nested generic.
@mhalbritter mhalbritter added type: task A general task and removed status: waiting-for-triage An issue we've not yet triaged labels Feb 27, 2024
@mhalbritter mhalbritter added this to the 3.1.x milestone Feb 27, 2024
scottfrederick pushed a commit that referenced this pull request Feb 27, 2024
This commit moves the resolution check for ConnectionDetailsFactory
to a dedicated method to make it more clear that it is meant to verify
that the implementation is resolved and can be loaded from the
classpath.

The previous algorithm relied on a behavior of ResolvableType that only
resolves the first level generics. Further improvements in Spring
Framework 6.2 make this check invalid as some implementations use a
Container that can hold a nested generic.

See gh-39737
@scottfrederick scottfrederick modified the milestones: 3.1.x, 3.1.10 Feb 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: task A general task
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants