相关文章推荐
逼格高的路灯  ·  解决使用Java ...·  3 月前    · 
含蓄的消炎药  ·  CVPR 2023 | ...·  1 年前    · 
爱运动的乌龙茶  ·  使用 ...·  1 年前    · 
Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

The application can persist users which can be modified later. Lately a user could not be modified and the HV000028 exception was thrown. The user entity was persisted without errors or validation. Does someone have an idea what could have caused such a behaviour or how I could find out more details?

2018-06-29 13:40:29,612 INFO  [stdout] (default task-48) Caused by: javax.validation.ValidationException: HV000028: Unexpected exception during isValid call.
2018-06-29 13:40:29,612 INFO  [stdout] (default task-48)        at org.hibernate.validator.internal.engine.constraintvalidation.ConstraintTree.validateSingleConstraint(ConstraintTree.java:451)
2018-06-29 13:40:29,612 INFO  [stdout] (default task-48)        at org.hibernate.validator.internal.engine.constraintvalidation.ConstraintTree.validateConstraints(ConstraintTree.java:127)
2018-06-29 13:40:29,612 INFO  [stdout] (default task-48)        at org.hibernate.validator.internal.engine.constraintvalidation.ConstraintTree.validateConstraints(ConstraintTree.java:87)
2018-06-29 13:40:29,612 INFO  [stdout] (default task-48)        at org.hibernate.validator.internal.metadata.core.MetaConstraint.validateConstraint(MetaConstraint.java:73)
2018-06-29 13:40:29,612 INFO  [stdout] (default task-48)        at org.hibernate.validator.internal.engine.ValidatorImpl.validateMetaConstraint(ValidatorImpl.java:592)
2018-06-29 13:40:29,612 INFO  [stdout] (default task-48)        at org.hibernate.validator.internal.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:555)
2018-06-29 13:40:29,612 INFO  [stdout] (default task-48)        at org.hibernate.validator.internal.engine.ValidatorImpl.validateConstraintsForDefaultGroup(ValidatorImpl.java:490)
2018-06-29 13:40:29,612 INFO  [stdout] (default task-48)        at org.hibernate.validator.internal.engine.ValidatorImpl.validateConstraintsForCurrentGroup(ValidatorImpl.java:454)
2018-06-29 13:40:29,612 INFO  [stdout] (default task-48)        at org.hibernate.validator.internal.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:406)
2018-06-29 13:40:29,612 INFO  [stdout] (default task-48)        at org.hibernate.validator.internal.engine.ValidatorImpl.validate(ValidatorImpl.java:204)
2018-06-29 13:40:29,612 INFO  [stdout] (default task-48)        at org.springframework.validation.beanvalidation.SpringValidatorAdapter.validate(SpringValidatorAdapter.java:253)
2018-06-29 13:40:29,612 INFO  [stdout] (default task-48)        at sun.reflect.GeneratedMethodAccessor427.invoke(Unknown Source)
2018-06-29 13:40:29,612 INFO  [stdout] (default task-48)        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
2018-06-29 13:40:29,612 INFO  [stdout] (default task-48)        at java.lang.reflect.Method.invoke(Method.java:498)
2018-06-29 13:40:29,613 INFO  [stdout] (default task-48)        at org.apache.wicket.proxy.LazyInitProxyFactory$JdkHandler.invoke(LazyInitProxyFactory.java:507)
2018-06-29 13:40:29,613 INFO  [stdout] (default task-48)        at com.sun.proxy.$Proxy287.validate(Unknown Source)
2018-06-29 13:40:29,613 INFO  [stdout] (default task-48)        at ch.lmv.ulm.web.page.template.BasePanel.doCompleteJSR303Validation(BasePanel.java:65)
2018-06-29 13:40:29,613 INFO  [stdout] (default task-48)        at ch.lmv.ulm.web.page.template.BasePanel.doCompleteJSR303Validation(BasePanel.java:49)
2018-06-29 13:40:29,613 INFO  [stdout] (default task-48)        at ch.lmv.ulm.web.page.person.EditPersonPanel$7.onSubmit(EditPersonPanel.java:420)
2018-06-29 13:40:29,613 INFO  [stdout] (default task-48)        at org.apache.wicket.ajax.markup.html.form.AjaxSubmitLink$1.onSubmit(AjaxSubmitLink.java:110)
2018-06-29 13:40:29,613 INFO  [stdout] (default task-48)        at org.apache.wicket.ajax.form.AjaxFormSubmitBehavior$AjaxFormSubmitter.onSubmit(AjaxFormSubmitBehavior.java:215)
2018-06-29 13:40:29,613 INFO  [stdout] (default task-48)        at org.apache.wicket.markup.html.form.Form.delegateSubmit(Form.java:1307)
2018-06-29 13:40:29,613 INFO  [stdout] (default task-48)        at org.apache.wicket.markup.html.form.Form.process(Form.java:974)
2018-06-29 13:40:29,613 INFO  [stdout] (default task-48)        at org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:795)
2018-06-29 13:40:29,613 INFO  [stdout] (default task-48)        at org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:171)
2018-06-29 13:40:29,613 INFO  [stdout] (default task-48)        at org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:155)
2018-06-29 13:40:29,613 INFO  [stdout] (default task-48)        at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:588)
2018-06-29 13:40:29,613 INFO  [stdout] (default task-48)        ... 82 more
2018-06-29 13:40:29,613 INFO  [stdout] (default task-48) Caused by: java.lang.NullPointerException

From your stack trace the validation failed on some NullPointerException, but it's on the last line. You should have posted a full stack trace.

Also please note, it's not a Hibernate (an ORM) that has caused the exception, but Hibernate Validator, which is a completely different thing.

This validator has a series of validations executed on input object that is called from wicket, see: ch.lmv.ulm.web.page.template.BasePanel.doCompleteJSR303Validation.

Now the bad part is that your logging system probably is not correctly configured. It's hard to say what exactly happens with your logging system, because you do not supply any details about it.

In a correct configuration, the exception with the stack-trace should be printed as a multiline string (one single INFO message) and not as a series of Messages (you have INFO on every single line, and it's wrong).

The correct way of calling the log (for example in slf4j framework) should be:

try {
   ... execute validation code
}catch (<SomeKindOfValidationExceptionYouExpectToGet> ex) {
   logger.error("Failed to validate <or better message>", ex); 

Note, that you pass an exception as an additional parameter here.

yes exactly, but unfortunately I only have this part of the stacktrace, since the log level was 'info'. – melanzane Jul 2, 2018 at 6:47 Thank you for the tip concerning the logging configuration. Do you have a tip on a good tutorial for log config? – melanzane Jul 2, 2018 at 7:07 Usually it depends on logging framework, and usually by default, it works like this. Do you catch the exception? if so, how do you print it? The good way is something like... (I'll update an answer with an example of a correct call), but if you need more details, I think its better to ask a separate question – Mark Bramnik Jul 2, 2018 at 7:12

Easy, it is because the user has submitted some value in the webpage form that has @NotNull annotation, and in the validator for the incoming request, when you detect the invalid null, some NPE is thrown in midst of validation, before Spring could throw its own InvalidArgumentException.

Most importantly, tell user to change its input, and change code to throw InvalidArgumentException so that the exception handler could do its job.

Thanks for contributing an answer to Stack Overflow!

  • Please be sure to answer the question. Provide details and share your research!

But avoid

  • Asking for help, clarification, or responding to other answers.
  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.