It would be useful the option of receive metadata about property to validate in a constraint. That is, the next possibility would be fantastic:

This is useful for:
- Obtaining the type, and do the validation in a way or another depend on type.
- Read other annotations of the same property. The the validation logic can depend on annotation combination.
- Using metadata from other part of the application that needs to be access from name of class/property.
- Doing validation based on the name of the property, or container class.

In OpenXava(http://www.openxava.org/) for example, the behaviour of @Required annotation is configurable by application, type and stereotype. We need to access to the metadata of the property in order to do the exact validation.

What do you think ?

Cheers
Javier Paniza

it would have to be isValid(object, metadata ...)
Otherwise you can have some multi threading issues I think, though I am not sure.

I am interested in the use cases behind your demand



You mean depending on the fact that it's a getter or a field? why does that matter? Java should have had a property feature anyway.


Hum, I kind of don't like that I think :) Can you give a concrete example?


I don't understand.


Can you give an example where it is useful?

Multi threading is not an problem because meta data is injected once. And metadata is static info. As in the case of initialize method.


Java already has a property feature based in convention. Even it has meta property classes, for example:
http://java.sun.com/j2se/1.5.0/docs/api ... iptor.html

But, if field versus getter is a big problem, injecting the Member is enough for me:
http://java.sun.com/j2se/1.5.0/docs/api ... ember.html



Of course:

In this case the @Required constraints does not behaves equals for a reference (@ManyToOne) and for a regular property.


In this case the @Required constraint has a special behaviour for @Hidden members.

When you write concrete constraints (as build in constraint of Hibernate Validator) this is not an issue, even it could be bad. But when you write constraint with an higher level of abstraction (as @Required for example) this feature is needed.


For example, we can have a properties as this:


And, in CreditLimit.properties we can have:

In addition of a properties file we also can use a xml file or even a database table.
That is we can configure the behaviour of the validation without recompile, and without redeploy. Application that can customize its logic in hot are VERY common, specially if you have your application deployed in several customers.


Yes.
For example:

The fact that this property is called 'name' means that is required at least 5 charecters in order to fulfil @Required constraint. We can regulate the semantic of the constraint based in the name of the member.
Really I don't like use this technique, but name convention are usual, remember the Java property feature itslef uses it.


I don't use my imagination for my proposals, instead I propose here things that already I am using for years.

Cheers

I am sorry, I still don't fully get you. How is @Required depending on other annotations? in your example. It seems that it depends on the type for sure but I don't see how @Hidden affects @Required.

The logic used in @Required for validation is not the same for a hidden member and for a non-hidden one.

The next example is extracted from a real application:


And in a validators.xml file we have:

In this way, we declare that in our application we use the NOT_NULL validation for enforce @Required for properties annotated with stereotype "MONEY". Thus we can refine the validation policy by application.
But, this type of things is not possible if we cannot access to member metadata.

Do you think that injecting a java.lang.reflect.Member (java.lang.reflect.Field or java.lang.reflect.Method) object to the constraint can be useful ?

So in your example what would be an alternative mapping that would force such flexibility?
Because for the poor user, you force him to set 2 annotations instead of one :)

@Stereotype("MONEY") and @Required have different meaning, we can have:

The behaviour of the constraint associated to @Required changes when the property to validate is @Stereotype("MONEY").

Anyways, this is only one of the multiple possibilities that access to metadata of the member can give us.

I completely agree in terms of required-ness and data type being independent. I'm currently using a custom annotations like the following:



I'm all for mechanisms in the API which support crawling out from underneath the normal validation scheme, into the larger body (metadata) of the code. The more non-invasive/optional flexibility we have, the better.

The other way I think about this... if the validation framework is going to use/find information X to decide to trigger a validation, then we should make sure we provide X to the custom validation, because it would be short-sighted to assume that the custom validation would not find X to be useful.

All of the context of the validation processing and execution should be available.