9

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
melanzane
  • 483
  • 1
  • 6
  • 16

3 Answers3

7

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.

halfer
  • 19,824
  • 17
  • 99
  • 186
Mark Bramnik
  • 39,963
  • 4
  • 57
  • 97
  • 3
    This should be a comment not answer. – Amith Kumar Jul 02 '18 at 06:46
  • yes exactly, but unfortunately I only have this part of the stacktrace, since the log level was 'info'. – melanzane Jul 02 '18 at 06:47
  • Thank you for the tip concerning the logging configuration. Do you have a tip on a good tutorial for log config? – melanzane Jul 02 '18 at 07: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 02 '18 at 07:12
1

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.

WesternGun
  • 11,303
  • 6
  • 88
  • 157
0

For me it was This

I solved by adding this to application.propperties

spring.jpa.properties.javax.persistence.validation.mode=none

overheated
  • 310
  • 4
  • 11