This feature is available in MyFaces ExtVal in the 3rd release.
Before the official release you can use it via the snapshot version.
... this version allows you to add general information to a constraint. You can think about it as an extension point for constraints.
Constraint aspects allow to provide a typesafe alternative. So you can provide an ExtVal add-on without knowing the concrete constraint implementation.
Only a central logic (e.g. an add-on) has to know what information might be available as parameter at the constraint and how to use this information.
The final usage is quite easy (see the next example).
So you can have add-on-X which provides new features and constraints Y (they don't know each other). But you can use the features of add-on-X with constraints Y (if they have an attribute of the type
Class<? extends ValidationParameter>)
How to use constraint parameters
Example usage of an ExtVal constraint + validation parameters:
You can see - the final usage is typesafe, shorter and the constraint isn't aware of the specific values behind.
So if you have existing constraints you just have to add an attribute of the type
Class<? extends ValidationParameter> and your constraint can automatically use any feature provided via a parameter implementation of ExtVal or an ExtVal add-on.
Stop reading here if you don't like to implement a custom parameter or if you don't like to query information of a parameter
Before you continue reading - constraint aspects don't replace "domain-attributes".
E.g. the values of min and max of
@Length are attributes of the constraint which might be different at every usage.
Furthermore, they aren't interesting for other constraints like
So it doesn't make sense to use a generic concept to replace such attributes.
Anyway, there are use-cases for shared features. ExtVal uses this mechanism e.g. for severities. Constraint aspects are interesting for features which allow a small set of possible values and which are interesting for different constraints of the whole application.
Without a generic solution you have to introduce one attribute per feature for every use-case at every constraint. And the implementation which uses these information have to be aware of all types of constraints (esp.: if you don't have a fix attribute name for it).
Constraint aspects allow you to extend the functionality of existing constraints.
Furthermore, they allow to introduce shared features. The implementations to process the information provided by the aspects/parameters aren't aware of the attribute name of the parameter nor of the concrete type of the constraint, parameter,... That means you provide a generic aspect attribute mechanism once and use it for different constraints and features.
You can query the parameters of a constraint at any time. (You just need access to the constraint.)
The important part is:
Class< ? extends ValidationParameter >
You can choose any attribute-name! (An array isn't required)
A parameter implementation has to implement this marker interface. The values within the implementation are marked via
@ParameterValue. Optionally you can provide @ParameterKey. If you don't specify an explicit key, the interface extending the ValidationParameter interface is the key.
Examples for possible parameter implementation styles
Parameter implementation - style 1
Direct implementation (just an interface - no concrete class) + grouped values
Parameter implementation - style 2
Direct implementation (just an interface - no concrete class) + key that doesn't introduce a class dependency
Parameter implementation - style 3
Class with implicit key + mixed value types + multiple values with the same type
Parameter implementation - style 4
Class with implicit key + the implementation provides the final value (the method isn't given by the interface) (PropertyValidationInterceptor extends ValidationParameter)
Parameter implementation - style 5
Class with implicit key + implicit value -> a simple marker
Parameter implementation - style 6 and 7
Details are available in ParameterTestCase#testParameterStyleSix
An use-case is available at os890.
Using the constraint and these parameter implementations
Query the information
As you see the extractor is a generic impl. which allows an easier usage of the constraint aspects.
You can see the signatures of the methods at: ValidationParameterExtractor.java
This concept isn't bound to ExtVal. ExtVal just provides one possible implementation which allows different parameter styles which are quite flexible in view of key/value aggregation and much more...