I am new bee using hibernate validator , I tried and managed to use it .I display the error message

by concatinating constraintViolation.getPropertyPath() and constraintViolation.getMessage()

the constraintViolation.getPropertyPath() returns the property name which is not user friendly , Is there a way I can customize the return value of constraintViolation.getPropertyPath() ?

Hi,


What do you mean w/ not user friendly? You are getting a Path instance returned. You can either just call toString on it or navigate the nodes to build your own custom string. What do you expect?

--Hardy

Assume getPropertyPath() returns auditDataSource instead I want "Source of Audit" is there any way can I tell hibernate validator to use my own string than property path , If I have to do myself then I need a map containing all propertypath as key and value my userfriendly string , can I annotate this at propettylevel ?

The property path is there to navigate to the property which failed the validation. It is not there to build a custom error message. It seems to me that you should use the message attribute of the constraint annotation, eg @NotNull(message="Source of Audit cannot be null"). Probably you want to move the message into your custom message bundle.

--Hardy

I know this post was quite old, but i am looking for the same thing.
I would like to do the following:



Then replace the default "ValidationMessages.properties" property with my own.



As you can see above, the propertyPathFriendlyName has to be looked up by the Custom Message Interpolator first before making it available in the context for the EL processor.

I have tried overriding and implementing my own Custom Message Interpolator, but it seems that the propertyPath is not available in the context passed into the Message Interpolator.

Did you find any elegant way of dealing with this?
My aim is to make it more implicit and to rid the programmers from having to write a lot of boilerplate stuff.

The property path is not available for message interpolation, so implementing a custom interpolator won't be of much help. As Hardy said, you could add the field's name to the message itself.

Alternatively you also might implement a custom solution which takes the property paths of any constraint violation, assembles a string by traversing the path nodes and uses this string for looking up a message in a custom message bundle. You also may consider to determine the type of a violation's leaf bean plus the property name (from the path's last node) and either form a message bundle key from that or even implement an annotation based solution which specifies the user-readable name of a property via an annotation.

Hth,

--Gunnar

Thanks for your suggestions!

I was kind of hoping that being the suggested validation api for EE, that it would support all use cases.
To me it would have made more sense passing the complete constraint validation info into the context of the message interpolator.
And then the responsibility of the message interpolator would be to set the message property.

I was trying to stick with standard apis and not go off the beaten track with proprietary framework code.
I also did not want to override both the validator and message areas to get it working in the standard api. (might reconsider later)

I realize that the typical usage will be to bind onto UI controls which already should have a label resource, so i might need to review my usage.

i will probably do one of the following for now, until i am sure my use case is correct:

That's the way it actually is done, only that the name of the concerned property (or the "path" leading to it) is not part of the message. I think that makes sense since in many cases the property name doesn't need to be shown (e.g. if the error label is given next to the concerned UI element) and it is framework specific how the user-readable name for a property should be determined, i.e. JSF may have other means for that as say GWT.



Right, take JSF for example. There the actual error message is taken from the constraint violation and put into another (customizable) message template which itself contains a placeholder for the actual error and another placeholder for the field name as configured via JSF. It might be possible to implement a similar solution for your case.

--Gunnar