-
-
Notifications
You must be signed in to change notification settings - Fork 528
Fixes for Spring Boot 3.5.0 API #3007
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -26,12 +26,15 @@ | |
|
||
package org.springdoc.core.providers; | ||
|
||
import java.util.List; | ||
import java.util.Optional; | ||
|
||
import jakarta.annotation.PostConstruct; | ||
|
||
import org.springframework.boot.autoconfigure.hateoas.HateoasProperties; | ||
import org.springframework.hateoas.mediatype.hal.Jackson2HalModule; | ||
import org.springframework.lang.NonNull; | ||
import org.springframework.util.ReflectionUtils; | ||
|
||
/** | ||
* The type Hateoas hal provider. | ||
|
@@ -79,8 +82,26 @@ protected void init() { | |
*/ | ||
public boolean isHalEnabled() { | ||
return hateoasPropertiesOptional | ||
.map(HateoasProperties::getUseHalAsDefaultJsonMediaType) | ||
.map(HateoasHalProvider::isHalEnabled) | ||
.orElse(true); | ||
} | ||
|
||
private static boolean isHalEnabled(@NonNull HateoasProperties hateoasProperties) { | ||
// In spring-boot 3.5, the method name was changed from getUseHalAsDefaultJsonMediaType to isUseHalAsDefaultJsonMediaType | ||
var possibleMethodNames = List.of("isUseHalAsDefaultJsonMediaType", "getUseHalAsDefaultJsonMediaType"); | ||
|
||
for (var methodName : possibleMethodNames) { | ||
var method = ReflectionUtils.findMethod(HateoasProperties.class, methodName); | ||
if (method != null) { | ||
var result = ReflectionUtils.invokeMethod(method, hateoasProperties); | ||
if (result instanceof Boolean halEnabled) { | ||
return halEnabled; | ||
} | ||
|
||
throw new IllegalStateException("Method " + methodName + " did not return a boolean value"); | ||
} | ||
} | ||
|
||
throw new IllegalStateException("No suitable method found to determine if HAL is enabled"); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Initial implementation defaults to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is already the case. Have a look at line 86 (formerly line 83). In my opinion, the exceptional behavior covered in There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No its not. Line 82 did map, this line throws--effectively bypassing the default. I totally get the difference here, but my point is that it is actually harmful because even if you dont use HAL at all your application wont start (and thats why I am here) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The throw on line 105 should only happen if There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No I haven't a demo. I am just in fearful expectation of experiencing this again. Bear in mind, for 10 days one is unable to use Spring-Boot 3.5.x with your product. To me this means "no security fixes to production the easy way" for 10 days. That is not really acceptable. Please be aware of that Spring doesn't view the properties (the getters) as part of their API, so they will absolutely change them if they feel like it. This would mean no deplyoments for as long as it takes for you to add another reflection-action-method here. God speed! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 3.4.x is still actively maintained FYI. |
||
} | ||
} |
Uh oh!
There was an error while loading. Please reload this page.
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.
Initial implementation defaults to
true
if no HateoasProperties are present. Could this also be applicable here?Uh oh!
There was an error while loading. Please reload this page.
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.
.orElse(true)
will still be called if theOptional<HateoasProperties> hateoasPropertiesOptional
is emptyUh oh!
There was an error while loading. Please reload this page.
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.
totally, but its sheer existence doesn't mean that it is important to the application.
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.
Sorry, I'm not following. If HATEOAS isn't available, the
.map()
call is a no-op here. This project needs to be compatible with upstream one way or another. If this project doesn't know how to figure out if HAL is active or not, then the only options here (as suggested by upstream) is to either use Reflection (as this PR does), or, to bump the min required version of SB to 3.5.0 and call the new method directly, at the expense of breaking compatibility with older versions of Spring Boot). If upstream changes the property methods yet again, silently returningtrue
if this project couldn't figure out how to determine if HAL is active or not is worse than bailing out IMO. But I'm not part of the springdoc team, so this is not my call.FWIW, this is far from the only problem blocking me from personally migrating to 3.5.0 at this point. There was a rather serious regression in, for example, spring-data-jpa. Unless more people test -RC releases or milestone releases of upstream, the
.0
release is really the first real shake out of problems and thats what we're seeing here.