-
Notifications
You must be signed in to change notification settings - Fork 38.3k
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
Data binding with java.util.Optional: traversal of nested paths, detection of empty holders [SPR-12241] #16855
Comments
Federico Donnarumma commented Do you have any workaround to fix this in the meantime? |
Juergen Hoeller commented Hibernate Validator itself doesn't seem to support Juergen |
Federico Donnarumma commented Hi Jurgen, as soon as I get back to the office I'll send you te code, but. I can say that getter and field are both Optional. |
Juergen Hoeller commented Fixed for Spring Framework 4.1.1 now, with BeanWrapper supporting the traversal of nested paths with Java 8 Optional declarations. Note that this only works for Spring data binding, i.e. getter methods for value access. We can't do anything about Hibernate Validator's lack of support for Optional fields; this is planned for Hibernate Validator 5.2 on their side. Juergen |
Juergen Hoeller commented Federico, please give the upcoming 4.1.1 snapshot a try and let me know whether the degree of Optional data binding support in there works for you. If for some reason the Optional field declaration works for your use of Hibernate Validator as well, then all the power to you! Juergen |
Federico Donnarumma commented Thanks Juergen, I'll give it a try ASAP, in the meantime I'll add a bug regarding TransactionContextHolder and TransactionalTestExecutionListener |
Federico Donnarumma commented Thanks Juergen, now it's working as expected. You are the man :) |
Federico Donnarumma commented Ok, not working for all cases, regression failed. Seems to fail when you use Optional.emtpy java.lang.IllegalArgumentException: Optional value must be present
at org.springframework.util.Assert.isTrue(Assert.java:65) ~[spring-core-4.1.1.BUILD-20140924.155845-31.jar:4.1.1.BUILD-SNAPSHOT]
at org.springframework.beans.BeanWrapperImpl$OptionalUnwrapper.unwrap(BeanWrapperImpl.java:1214) ~[spring-beans-4.1.1.BUILD-20140924.155845-31.jar:4.1.1.BUILD-SNAPSHOT] |
Federico Donnarumma commented Not working for Optional.empty |
Juergen Hoeller commented What are the next few lines in the stacktrace there? We can't bind against an empty Optional object, so we're treating it like a null value... rejecting it where a null value would get rejected as well. Are we getting that wrong somewhere? Juergen |
Federico Donnarumma commented The assert seems to be wrong. An empty optional is still an Optional Optional<?> optional = (Optional<?>) optionalObject;
Assert.isTrue(optional.isPresent(), "Optional value must be present"); Full stack.
|
Juergen Hoeller commented I figured it'd be a top-level binding target like in that stacktrace... Note that we are rejecting a null value in such a scenario since we can't bind any properties against a null target; with the same reasoning, we're rejecting an empty Optional object as well. So I'm wondering: What would you expect to happen in such a case? Any incoming property values could not get bound since there's no target object... Would you expect that to fail later - i.e. on actual binding of a property value, with possibly none specified anyway, therefore effectively skipping the binding step? Juergen |
Federico Donnarumma commented I don't get why it's failing. We are using a custom validator that validates the object inside the Optional so if the controller is mapping that to an empty optional that seems fine, can you clarify a little more? Thanks in advance. |
Federico Donnarumma commented what do you think about this? public static Object unwrap(Object optionalObject) {
Optional<?> optional = (Optional<?>) optionalObject;
if(optional.isPresent()) {
return optional.get();
} else {
return Optional.empty();
}
} |
Juergen Hoeller commented Ah, that problem seems to be in In any case, an empty Optional object ending up as top-level object in Juergen |
Juergen Hoeller commented Seems we posted at the same time! Refining the assertion that way would allow for entering code paths in Juergen |
Federico Donnarumma commented Great, thanks for your help. This Java 8 Optional thing is giving us a couple of headaches. |
Juergen Hoeller commented DataBinder unwraps Optional objects and allows for proper handling of Juergen |
Federico Donnarumma commented Great, I'll give it a try with SNAPSHOT release. |
Federico Donnarumma commented Works great, thanks Juergen. Do you have an estimated release date for Spring 4.1.1? |
Juergen Hoeller commented Cool, thanks for the immediate feedback! 4.1.1 is scheduled for next week (Sep 30). You can always check the JIRA roadmap - we usually keep the release targets up to date there. Juergen |
Federico Donnarumma opened SPR-12241 and commented
Hi, I have this case, when validating with JSR-303.
I Have an object which contains an Optional, when SpringValidatorAdapter cycles through properties to show something of the style
"you entered 0 but field nights should be higher than 0"
BeanWrapper can't access the object inside the Optional and I get this message:
Affects: 4.1 GA
Issue Links:
@Inject
(a la@Autowired
's required=false)Referenced from: commits cfc821d, 0934751
The text was updated successfully, but these errors were encountered: