Compatibility problems with the Hibernate validation API [was: overuse of final keyword]

[jamesdbloom]

Why has almost every class used the final keyword? This makes it impossible to extend any functionality or to write effective tests.

[fge]

I agree that in some places this keyword is overused -- in particular I even make parameters in interfaces final.

For the rest, it is purely a design choice. You will notice that despite the "overuse" of the final keyword, the API is completely and fully tested! The core parts of the API (keyword validators, etc) are all interfaces or abstract classes; which allows you to test your own keywords, and the API itself to be tested.

With what classes do you have a problem exactly with them being final? Given the way the API is built, it is 100% sure that you can make fail/succeed whatever you want

[fge]

Also, don't forget that all core components are in fact Processors; this is a little known fact, and the validator itself is also a Processor (mind you, given my poor mastery of generics at the time when I wrote this code, it is not as good as it should be).

So if you want to "add functionality" as you say, you can also use that.

[jamesdbloom]

ok fair enough, perhaps I was a little strong. However, I'm struggling with an issue. I'm trying to get specific error messages specified from a custom resource bundle.

The use case it that I want to replace the @Valid annotation in Spring MVC with schema validation using your framework. However I need to be able to control the exact error messages (or error codes) being returned. One way I was trying to do this was to get at the internal values in a ProcessingMessage, but this does not work due to the use of multiple final keywords. The only way I found round this was to convert the ProcessingMessage.toJson() then read the values out of the json which feels wrong.

Is there a more sensible way to return custom error messages (without redefining the validators).

Thanks

[fge]

Hmm...

Which messages are you talking about exactly? If they are all tied to a MessageBundle then you can submit a different MessageBundle at initialization time -- even building upon the default one.

I admit that there is one thing missing from the package as a whole, and that is dependency injection; alas, this is too late for 2.2.x, but it is a plan for 3.0.x -- as long as I can figure out when NOT to use it, and that's the difficult part.

So, can you tell which part you have a problem with exactly?

[jamesdbloom]

What I would like to do is either:

• a context specific error code, with field path and error type i.e.:

String messageCode = "err." + processingMessage.asJson().get("instance").get("pointer").asText().replaceFirst("/", "").replaceAll("/", ".") + "." + processingMessage.asJson().get("keyword").asText();

• a way to specify the message using a message bundle with key format as above i.e.:

err.number.type = please enter a number
err.status.enum = please enter a valid status value
err.message.maxLength = please enter a message between 5 and 50 characters
err.message.minLength = please enter a message between 5 and 50 characters
err.required = please enter all required fields

The first item would allow me to use my own message bundle and pull out the messages I want. This would give me complete control to use either the existing message you provide or my own custom messages. This would provide a very simple extension that would be simple to use.

The second approach would make the solution more complete but at the expense of losing some control. In addition the current issue with libraries like Spring MVC and Hibernate Validator is that it can be hard to get the library to find the correct message bundle and message key. If you look online you'll see a lot of people complaining about that. The second approach could suffer this same issue as the message bundle would have to be defined using expected keys and naming so that the correct message can be found.

The final thing to say is exposing the arguments (used internally in the ProcessingMessage class) would also be helpful as they include information that it might be helpful to add into a formatted message.

[jamesdbloom]

I would be happy to submit a pull request to add this if you like?

[fge]

If you look online you'll see a lot of people complaining about that.

Well, I admit that in the past few months that project has not been my priority (I am currently working on Java 7 (underused) FileSystems.

I also admit that of the Hibernate Validator API, I only know the name; therefore what I'd like to see is the complaints people have first and foremost, it will give me an idea. Another item I have to do for the next version is schema inlining, as this is a VERY common request...

So, first of all, can you provide me with some links, and your own comments if any? Then we will work out what the best way to achieve your objectives (which I still cannot fully understand at this point) are.

[jamesdbloom]

ok I'll see what I can dig up in the way of examples, etc.