@ValidatedFor annotation support for validation groups #137

fcamblor · 2014-12-29T09:58:28Z

Proposal to support bean validation groups during validation.

I'm not really satisfied by the current implementation and would like to open the discussion about it.

At first, I was planning to implement usage below :

    @PermitAll
    @POST("/valid/pojos")
    public void createPOJOWithoutAnnotation(POJO myPojo) { // No @ValidatedFor annotation => Default validation group will be implicitly used here, keeping backward compat behaviour
        LOG.info("Pojo {} {} created !", myPojo.getName(), myPojo.getSubPOJO().getLabel());
    }

    @PermitAll
    @POST("/valid/pojos2")
    public void createPOJOWithAnnotation(@ValidatedFor(FormValidations.Create.class) POJO myPojo) { // Here, defining we want to activate the Create validation group mode on validation
        LOG.info("Pojo {} {} created !", myPojo.getName(), myPojo.getSubPOJO().getLabel());
    }

    @PermitAll
    @PUT("/valid/pojos/{id}")
    public void createPOJOWithoutAnnotation(Long id, @ValidatedFor({MyCustomValidationGroup.class, FormValidations.Update.class}) POJO myPojo) { // Multiple validation groups can be provided, following bean validation's Validator API
        LOG.info("Pojo {} {} updated !", myPojo.getName(), myPojo.getSubPOJO().getLabel());
    }

with group declaration :

public interface FormValidations {
    public static interface Create extends Default{}
    public static interface Update extends Default{}
}

public class ValidationResource {
// ...
    public static interface MyCustomValidationGroup{}
// ...
}

But I faced some issues at annotation processing time when retrieving @ValidatedFor.value() classes : didn't completely understood why, but some classes (either in restx-core or in samplest) were not accessible.
You can see some testing I made in commit 7f88a79 (from branch validations-validatedfor-with-class, some github comments describe what's going weird)

Thus, I had to fallback from Class[] to String[] in order to directly provide validation group FQN used for source generation.
Which makes declaration look like :

    @PermitAll
    @POST("/valid/pojos")
    public void createPOJOWithoutAnnotation(POJO myPojo) {
        LOG.info("Pojo {} {} created !", myPojo.getName(), myPojo.getSubPOJO().getLabel());
    }

    @PermitAll
    @POST("/valid/pojos2")
    public void createPOJOWithAnnotation(@ValidatedFor(FormValidations.CreateFQN) POJO myPojo) {
        LOG.info("Pojo {} {} created !", myPojo.getName(), myPojo.getSubPOJO().getLabel());
    }

    @PermitAll
    @PUT("/valid/pojos/{id}")
    public void createPOJOWithoutAnnotation(Long id, @ValidatedFor({MyCustomValidationGroupFQN, FormValidations.UpdateFQN}) POJO myPojo) {
        LOG.info("Pojo {} {} updated !", myPojo.getName(), myPojo.getSubPOJO().getLabel());
    }

and group declaration :

public interface FormValidations {
    public static final String DefaultFQN = "javax.validation.groups.Default";
    public static final String CreateFQN = "restx.validation.stereotypes.FormValidations.Create";
    public static interface Create extends Default{}
    public static final String UpdateFQN = "restx.validation.stereotypes.FormValidations.Update";
    public static interface Update extends Default{}
}

public class ValidationResource {
// ...
    public static interface MyCustomValidationGroup{}
    public static final String MyCustomValidationGroupFQN = "samplest.validation.ValidationResource.MyCustomValidationGroup";
// ...
}

If you see any workaround for this issue, I'm opened to discuss it.

Another way would be to rely on reflection but I know this is something we should avoid, especially for such trivial things.

…[BREAKING]

…e to new restx-validation module. [BREAKING] It means that to activate bean validation, you will need to explicitely add a dependency on restx-validation module on your project. Startup time on project not using restx-validation will then be improved (no hibernate validator will be loaded) for ~250ms

…"hibernate.validator") [BREAKING]

@SiZe

…, in order to make interpolation work in validation error messages (like @SiZe)

validation groups which will be used during bean validation

…date POJO against bean validation groups

…lidation validator

… samplest module

fcamblor · 2014-12-29T10:16:30Z

On another topic, I'm thinking about generating checkValid() checks on query object parameters.

I'm just wondering if I should make this as a default behaviour (thus breaking backward compatibility) or enabling it only when @ValidatedFor annotation is placed over these query parameters.

I'm not a big fan of the latter since we would have a different behaviour between body and query parameter validation (the first one not requiring @ValidatedFor and the latter requiring it)
WDYT ?

xhanin · 2014-12-30T23:38:40Z

Hi,

Sounds nice overall!

For the problem of using the Class directly on the annotation, I think I've found how to use it. Here is a method that will return the list of classes as fully qualified names in Strings:

    public String[] getAnnotationClassValuesAsFQCN(VariableElement p, Class annotationClazz, String methodName) {
        List<? extends AnnotationMirror> annotationMirrors = p.getAnnotationMirrors();
        for (AnnotationMirror annotationMirror : annotationMirrors) {
            if (annotationMirror.getAnnotationType().toString().equals(annotationClazz.getCanonicalName())) {
                for (Map.Entry<? extends ExecutableElement, ? extends AnnotationValue> entry : annotationMirror.getElementValues().entrySet()) {
                    if (entry.getKey().getSimpleName().contentEquals(methodName)) {
                        Array array = (Array) entry.getValue();

                        List<String> fqcns = new ArrayList<>();
                        for (Attribute attribute : array.getValue()) {
                            ClassType type = (ClassType) attribute.getValue();
                            fqcns.add(type.toString());
                        }
                        return fqcns.toArray(new String[fqcns.size()]);
                    }
                }
            }
        }
        return null;
    }

I've tried calling it like this:

            ValidatedFor validatedFor = p.getAnnotation(ValidatedFor.class);

            String[] validationGroups = new String[0];
            if(validatedFor != null) {
                validationGroups = getAnnotationClassValuesAsFQCN(p, ValidatedFor.class, "value");
            }

and it seems to work as expected, tests are passing.

Now about extracting it in a separate module, indeed the module is very simple, but as you say it makes it more pluggable, so I'm ok for it. I'd just add a md.restx.json file to the module to generate the pom from it.

Last, about validating query parameters, why not now that they also use ObjectMapper for mapping it would make them fully consistent, despite I don't think people will often use domain objects in query parameters. My only objection would be if it impacts performance significantly. I haven't done any tests on how much it costs to try to validate an object that has no validation. Do you have an idea?

xhanin · 2014-12-30T23:41:47Z

And about "tuning classes for hibernate validator performance at startup (even if nowadays, I didn't found such sort of configuration classes)" the call to ignoreXmlConfiguration() is actually a startup perf tuning.

…datedFor.value() since in most of cases, plain Class instance won't be available yet at annotation processing time Note that current impl has a drawback by relying on com.sun.tools.javac.code hidden package

…ation() call if needed

… file

fcamblor · 2015-01-03T13:44:24Z

Just made some benchmarking with JMH about the validator.validate() calls.

Here is a tldr; of the benchmark results :

Notes:
- "ss" stands for "single shot" (that is to say only 1 operation call after warmup)
- Time scores are expressed in seconds (with ms precision)
- In "sample" mode, I made 8 warmup iterations, 1s each, and 10 measurement iterations, 1s each.
  6 forks (=occurences) are made of these warmups+iterations.
  This means 1019698 on 1 benchmark implies we made 10 x 1000ms x 6
- No multithreading during this benchmarks


Benchmark                                                                                              Mode  Samples  Score   Error  Units
i.r.ValidationBenchmark.testValidatorWithFewConstraintOnEmptyPOJO                                    sample  1019698  0.000 ? 0.000   s/op
i.r.ValidationBenchmark.testValidatorWithFewConstraintOnFullPOJO                                     sample  1047799  0.000 ? 0.000   s/op
i.r.ValidationBenchmark.testValidatorWithFewConstraintOnPOJO                                         sample  1090202  0.000 ? 0.000   s/op
i.r.ValidationBenchmark.testValidatorWithLotsOfConstraintOnEmptyPOJO                                 sample   470899  0.000 ? 0.000   s/op
i.r.ValidationBenchmark.testValidatorWithLotsOfConstraintOnFullPOJO                                  sample   418788  0.000 ? 0.000   s/op
i.r.ValidationBenchmark.testValidatorWithLotsOfConstraintOnPOJO                                      sample   372808  0.000 ? 0.000   s/op
i.r.ValidationBenchmark.testValidatorWithNoConstraintOnEmptyPOJO                                     sample   793554  0.000 ? 0.000   s/op
i.r.ValidationBenchmark.testValidatorWithNoConstraintOnFullPOJO                                      sample   864629  0.000 ? 0.000   s/op
i.r.ValidationBenchmark.testValidatorWithNoConstraintOnPOJO                                          sample   850216  0.000 ? 0.000   s/op
i.r.SingleShotWith1ValidateWarmupValidationBenchmark.testValidatorWithFewConstraintOnEmptyPOJO           ss       60  0.001 ? 0.000      s
i.r.SingleShotWith1ValidateWarmupValidationBenchmark.testValidatorWithFewConstraintOnFullPOJO            ss       60  0.000 ? 0.000      s
i.r.SingleShotWith1ValidateWarmupValidationBenchmark.testValidatorWithFewConstraintOnPOJO                ss       60  0.001 ? 0.000      s
i.r.SingleShotWith1ValidateWarmupValidationBenchmark.testValidatorWithLotsOfConstraintOnEmptyPOJO        ss       60  0.004 ? 0.000      s
i.r.SingleShotWith1ValidateWarmupValidationBenchmark.testValidatorWithLotsOfConstraintOnFullPOJO         ss       60  0.003 ? 0.000      s
i.r.SingleShotWith1ValidateWarmupValidationBenchmark.testValidatorWithLotsOfConstraintOnPOJO             ss       60  0.004 ? 0.000      s
i.r.SingleShotWith1ValidateWarmupValidationBenchmark.testValidatorWithNoConstraintOnEmptyPOJO            ss       60  0.000 ? 0.000      s
i.r.SingleShotWith1ValidateWarmupValidationBenchmark.testValidatorWithNoConstraintOnFullPOJO             ss       60  0.000 ? 0.000      s
i.r.SingleShotWith1ValidateWarmupValidationBenchmark.testValidatorWithNoConstraintOnPOJO                 ss       60  0.000 ? 0.000      s
i.r.SingleShotWithNoWarmupValidationBenchmark.testValidatorWithFewConstraintOnEmptyPOJO                  ss       60  0.017 ? 0.022      s
i.r.SingleShotWithNoWarmupValidationBenchmark.testValidatorWithFewConstraintOnFullPOJO                   ss       60  0.014 ? 0.019      s
i.r.SingleShotWithNoWarmupValidationBenchmark.testValidatorWithFewConstraintOnPOJO                       ss       60  0.014 ? 0.018      s
i.r.SingleShotWithNoWarmupValidationBenchmark.testValidatorWithLotsOfConstraintOnEmptyPOJO               ss       60  0.023 ? 0.025      s
i.r.SingleShotWithNoWarmupValidationBenchmark.testValidatorWithLotsOfConstraintOnFullPOJO                ss       60  0.024 ? 0.027      s
i.r.SingleShotWithNoWarmupValidationBenchmark.testValidatorWithLotsOfConstraintOnPOJO                    ss       60  0.027 ? 0.032      s
i.r.SingleShotWithNoWarmupValidationBenchmark.testValidatorWithNoConstraintOnEmptyPOJO                   ss       60  0.010 ? 0.014      s
i.r.SingleShotWithNoWarmupValidationBenchmark.testValidatorWithNoConstraintOnFullPOJO                    ss       60  0.013 ? 0.018      s
i.r.SingleShotWithNoWarmupValidationBenchmark.testValidatorWithNoConstraintOnPOJO                        ss       60  0.012 ? 0.016      s
i.r.ValidationBenchmark.testValidatorWithFewConstraintOnEmptyPOJO                                        ss       60  0.001 ? 0.001      s
i.r.ValidationBenchmark.testValidatorWithFewConstraintOnFullPOJO                                         ss       60  0.001 ? 0.000      s
i.r.ValidationBenchmark.testValidatorWithFewConstraintOnPOJO                                             ss       60  0.001 ? 0.000      s
i.r.ValidationBenchmark.testValidatorWithLotsOfConstraintOnEmptyPOJO                                     ss       60  0.004 ? 0.000      s
i.r.ValidationBenchmark.testValidatorWithLotsOfConstraintOnFullPOJO                                      ss       60  0.006 ? 0.005      s
i.r.ValidationBenchmark.testValidatorWithLotsOfConstraintOnPOJO                                          ss       60  0.004 ? 0.000      s
i.r.ValidationBenchmark.testValidatorWithNoConstraintOnEmptyPOJO                                         ss       60  0.000 ? 0.000      s
i.r.ValidationBenchmark.testValidatorWithNoConstraintOnFullPOJO                                          ss       60  0.000 ? 0.000      s
i.r.ValidationBenchmark.testValidatorWithNoConstraintOnPOJO                                              ss       60  0.000 ? 0.000      s

Full log can be seen in this gist, and benchmark sources can be seen here.

My thoughts about this benchmarking results :

Over time, the validation call is negligible : with 8s warmup, we make approx 17k validate() per seconds (it takes ~0.05ms per operation)
First validate() calls take time (in the benchmark, we have a mean time of ~20ms ± ~20ms ... when executing it by hand (=without JMH instrumentation), in ValidationBenchmark.main(), I have even greater numbers (~100-200ms)
Second validate() call is largely faster, about 1ms
I suppose the first call put validation annotations metadata into a cache to speed up upcoming calls
Note that the JIT compiler seems to better optimize this over time (see first bullet point)

I tested in real life the bean validation behaviour to see how it behaves on hot reload/compile (my comments in the logs below, starting with ##) :

starting samplest.AppServer... - type `stop` to stop it and go back to restx shell
2015-01-03 14:18:35,212 [main            ] [          ] INFO  restx.RestxMainRouterFactory - LOADING MAIN ROUTER
2015-01-03 14:18:35,219 [main            ] [          ] INFO  restx.RestxMainRouterFactory -
--------------------------------------
 -- RESTX >> LOAD ON REQUEST << >> DEV MODE << >> AUTO COMPILE <<
 -- for admin console,
 --   VISIT http://127.0.0.1:8080/api/@/ui/
 --

2015-01-03 14:18:35,729 [main            ] [          ] INFO  restx.classloader.CompilationManager - watching for changes in [src/main/java, src/main/resources]; current location is /Users/fcamblor/Documents/projects/restx/restx-samplest/.
2015-01-03 14:18:35,777 [main            ] [          ] INFO  restx.monitor.MetricsConfiguration - registering Metrics JVM metrics
2015-01-03 14:18:54,955 [Dispatcher: Thread-8] [          ] INFO  o.h.validator.internal.util.Version - HV000001: Hibernate Validator 5.0.1.Final
2015-01-03 14:18:55,108 [Dispatcher: Thread-8] [          ] INFO  restx.RestxMainRouterFactory - [RESTX REQUEST] GET /@/ui/ - per request factory created in 601.4 ms
2015-01-03 14:18:55,386 [Dispatcher: Thread-20] [          ] INFO  restx.RestxMainRouterFactory - [RESTX REQUEST] GET /@/ui/js/admin.js - per request factory created in 227.3 ms
2015-01-03 14:18:55,387 [Dispatcher: Thread-13] [          ] INFO  restx.RestxMainRouterFactory - [RESTX REQUEST] GET /@/ui/css/admin.css - per request factory created in 252.6 ms
2015-01-03 14:18:55,391 [Dispatcher: Thread-14] [          ] INFO  restx.RestxMainRouterFactory - [RESTX REQUEST] GET /@/ui/css/bootstrap.min.css - per request factory created in 256.8 ms
2015-01-03 14:18:55,410 [Dispatcher: Thread-19] [          ] INFO  restx.RestxMainRouterFactory - [RESTX REQUEST] GET /@/ui/js/securityHandling.js - per request factory created in 250.7 ms
2015-01-03 14:18:55,821 [Dispatcher: Thread-24] [          ] INFO  restx.StdRestxMainRouter - << [RESTX REQUEST] GET /@/pages >> UNAUTHORIZED - 20.53 ms
2015-01-03 14:18:55,824 [Dispatcher: Thread-25] [          ] INFO  restx.StdRestxMainRouter - << [RESTX REQUEST] GET /sessions/current >> UNAUTHORIZED - 1.454 ms
## Here, I created a new Session, this means I'm sure Validator @Component has already bean created since Session instance should have been validated
2015-01-03 14:19:09,885 [Dispatcher: Thread-14] [          ] INFO  restx.StdRestxMainRouter - << [RESTX REQUEST] POST /sessions >> OK - 459.3 ms
2015-01-03 14:19:10,219 [Dispatcher: Thread-14] [admin     ] INFO  restx.StdRestxMainRouter - << [RESTX REQUEST] GET /sessions/current >> OK - 10.51 ms
2015-01-03 14:19:10,220 [Dispatcher: Thread-23] [admin     ] INFO  restx.StdRestxMainRouter - << [RESTX REQUEST] GET /@/pages >> OK - 12.14 ms
## First POJO creation, it took ~86ms for first validation
2015-01-03 14:19:52,478 [Dispatcher: Thread-8] [admin     ] INFO  s.validation.ValidationResource - Pojo blah a very long label created !
2015-01-03 14:19:52,479 [Dispatcher: Thread-8] [admin     ] INFO  restx.StdRestxMainRouter - << [RESTX REQUEST] POST /valid/pojos2 >> NO_CONTENT - 86.33 ms
## Next POJO creation (with same content as previous one), request took ~18ms, behaving as expected with the benchmark
2015-01-03 14:20:04,130 [Dispatcher: Thread-24] [admin     ] INFO  s.validation.ValidationResource - Pojo blah a very long label created !
2015-01-03 14:20:04,131 [Dispatcher: Thread-24] [admin     ] INFO  restx.StdRestxMainRouter - << [RESTX REQUEST] POST /valid/pojos2 >> NO_CONTENT - 18.39 ms
## Subsequent POJO creation took the same amount of time (approx)
2015-01-03 14:20:07,050 [Dispatcher: Thread-25] [admin     ] INFO  s.validation.ValidationResource - Pojo blah a very long label created !
2015-01-03 14:20:07,052 [Dispatcher: Thread-25] [admin     ] INFO  restx.StdRestxMainRouter - << [RESTX REQUEST] POST /valid/pojos2 >> NO_CONTENT - 20.72 ms
## Here, I added a new field in POJO (with no bean validation constraint on it) to trigger a re-compilation for POJO class and see how would behave bean validation
2015-01-03 14:20:42,106 [pool-2-thread-1 ] [          ] INFO  restx.classloader.CompilationManager - compilation finished: 1 sources compiled in 769.2 ms
## Re-submitted POJO instance with same content ... it took 18ms ... so it looked like bean validation kept and reused the annotation cached metadata
2015-01-03 14:20:49,290 [Dispatcher: Thread-13] [admin     ] INFO  s.validation.ValidationResource - Pojo blah a very long label created !
2015-01-03 14:20:49,291 [Dispatcher: Thread-13] [admin     ] INFO  restx.StdRestxMainRouter - << [RESTX REQUEST] POST /valid/pojos2 >> NO_CONTENT - 18.95 ms
## Same behaviour on new POJO instance creation, no surprise here
2015-01-03 14:20:53,246 [Dispatcher: Thread-14] [admin     ] INFO  s.validation.ValidationResource - Pojo blah a very long label created !
2015-01-03 14:20:53,247 [Dispatcher: Thread-14] [admin     ] INFO  restx.StdRestxMainRouter - << [RESTX REQUEST] POST /valid/pojos2 >> NO_CONTENT - 18.41 ms
## Here, I put a @NotNull constraint on my new field, which triggered a new compilation
2015-01-03 14:21:16,389 [pool-2-thread-1 ] [          ] INFO  restx.classloader.CompilationManager - compilation finished: 1 sources compiled in 247.4 ms
## Then, I issued a new POJO creation, always with the same content, expecting a validation exception because my new field value was missing...
2015-01-03 14:21:20,327 [Dispatcher: Thread-23] [admin     ] INFO  s.validation.ValidationResource - Pojo blah a very long label created !
2015-01-03 14:21:20,328 [Dispatcher: Thread-23] [admin     ] INFO  restx.StdRestxMainRouter - << [RESTX REQUEST] POST /valid/pojos2 >> NO_CONTENT - 36.33 ms
## And BAM ! No validation error here !
## Note that if I restarted restx (thus clearing bean validation cache), the same request triggered a validation exception

=> We can make 2 conclusions here :

Seems like the validation overhead takes ~60ms only at first validation..
I think it is OK to implement a checkValid() call on query parameters, except for Raw types and String
We have an issue with hot compile/reload and bean validation cache : new validation constraints added on beans are not taken into account during a hot compile/reload
I will create a new dedicated issue about this topic (unrelated to current PR).

Do you agree with these assumptions ?

…to avoid some backward incompatibilities on existing generated code

xhanin · 2015-01-03T17:21:30Z

Thanks for this thorough analysis, and I agree with your conclusions. Having a separate issue for hot reload is fine, it's not due to the changes introduced here and can be addressed separately.

BTW for using classes on @ValidatedFor did you try what I proposed? Do you need more information?

fcamblor · 2015-01-03T17:47:09Z

Yup no problems with your implementation thanks for it.
I pushed d65fd01 today (with some other commits relating to previous discussions)

I'll implement checkValid on query parameters, then push and ping here for latest review.
Once approve I'll merge it on master manually (some conflicts occured on changes I made on README.md on both branches)

xhanin · 2015-01-03T19:02:57Z

Perfect, thanks.

Xavier
Le 3 janv. 2015 18:47, "Frédéric Camblor" notifications@github.com a
écrit :

Yup no problems with your implementation thanks for it.
I pushed d65fd01
d65fd01
today (with some other commits relating to previous discussions)

I'll implement checkValid on query parameters, then push and ping here
for latest review.
Once approve I'll merge it on master manually (some conflicts occured on
changes I made on README.md on both branches)

—
Reply to this email directly or view it on GitHub
#137 (comment).

fcamblor · 2015-01-04T23:36:58Z

I just started to implement checkValid on query parameters and it doesn't sound possible (yet).

Particularly when looking at RestxAnnotationProcessor which seems to only handle String as query parameters (see the request.getQueryParam("%s") call which will return a String only)

I'm wondering if I'm looking at the right place you expected me to generate checkValid to since it doesn't fit well with your sentence :

Last, about validating query parameters, why not now that they also use ObjectMapper for mapping it would make them fully consistent, despite I don't think people will often use domain objects in query parameters.

The use case I see (and use on a regular basis) for POJOs in query parameters is search criteria.
I like using URI like this one to search for data : /myresources?ids=1&ids=2&labelLooksLike=foo
with underlying POJO class :

public class MyResourceSearchCriteria {
    Long[] ids;
    String labelLooksLike;

    @AssertTrue
    public boolean atLeastOneParamSet(){
        return (ids != null && ids.length>0) || (labelLooksLike != null && labelLooksLike.length()>0);
    }

    public Long[] getIds() {
        return ids;
    }

    public void setIds(Long[] ids) {
        this.ids = ids;
    }

    public String getLabelLooksLike() {
        return labelLooksLike;
    }

    public void setLabelLooksLike(String labelLooksLike) {
        this.labelLooksLike = labelLooksLike;
    }
}

.. but it doesn't seem to be supported yet by restx.

If we need to support this prior to calling checkValid on request parameters, I'll merge this PR first an plan this change later.

xhanin · 2015-01-05T07:47:15Z

The use of ObjectMapper is done in MainStringConverter, and actually you introduced it in 6b5d058 :)

Still the usage is limited, it only convert one parameter at a time, and doesn't support List of parameters (there is a TODO for the latter in the code). So currently you can have a POJO as query parameter but then you need to JSON encode it in a single query param, which is not very "RESTful".

Supporting your example would really be interesting, but it requires some changes in the API: currently the StringConverter takes the value to convert as String, here we would need a more specialized API taking the RestxRequest and being in charge of extracting the query parameters from the request.

But that would better go in a separate issue / PR.

WDYT?

fcamblor · 2015-01-22T05:29:45Z

Merged through a516b4e

fcamblor added 10 commits December 22, 2014 14:15

validation - Considering Validator components as optional components …

6b440af

…[BREAKING]

validation - Updated name for default Validator (from "validator" to …

91891fe

…"hibernate.validator") [BREAKING]

validation - Providing el api & impl dependencies in restx-validation…

616a005

…, in order to make interpolation work in validation error messages (like @SiZe)

validation - added restx-validation dep on restx-samplest

4d90301

validation - Preparing ResourceMethodParameter to allow to pass it

0ad8d57

validation groups which will be used during bean validation

Introduced @ValidatedFor annotation which will be used (soon) to vali…

84eab2d

…date POJO against bean validation groups

validation - Providing @ValidatedFor validation groups to the bean va…

6d9e8f2

…lidation validator

validation - Provided samplest test cases for validation groups

4ab2106

Provided some plugin commented code to debug annotation processing on…

4afdbce

… samplest module

fcamblor force-pushed the master branch 2 times, most recently from c49578f to 710f27e Compare December 30, 2014 16:19

fcamblor added 3 commits January 2, 2015 12:45

validation - Fixing some ClassNotFoundException when retrieving @Vali…

d65fd01

…datedFor.value() since in most of cases, plain Class instance won't be available yet at annotation processing time Note that current impl has a drawback by relying on com.sun.tools.javac.code hidden package

validation - provided named component to ignore the ignoreXmlConfigur…

333ea6a

…ation() call if needed

validation - Provided md.restx.json file and corresponding module.ivy…

28a7379

… file

validation - Provided deprecated Validations.checkValid(Validator,T) …

8be4965

…to avoid some backward incompatibilities on existing generated code

fcamblor force-pushed the validations-enhancements branch from a3d9a09 to 8be4965 Compare January 3, 2015 13:54

validation - Added restx-validation module description in README

6bff1cc

fcamblor force-pushed the validations-enhancements branch from b960e7d to 6bff1cc Compare January 3, 2015 14:00

fcamblor mentioned this pull request Jan 5, 2015

Hot reload/compile doesn't fit well with bean validation #139

Closed

fcamblor added a commit to fcamblor/restx that referenced this pull request Jan 22, 2015

Merge branch 'validations-enhancements' into master, fixing restx#137

a516b4e

fcamblor closed this Jan 22, 2015

This was referenced Jan 22, 2015

Provide defined ValidationGroup in api-docs #145

Open

Better query parameters handling : List support, POJO support, Bean validation support #146

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

@ValidatedFor annotation support for validation groups #137

@ValidatedFor annotation support for validation groups #137

fcamblor commented Dec 29, 2014

fcamblor commented Dec 29, 2014

xhanin commented Dec 30, 2014

xhanin commented Dec 30, 2014

fcamblor commented Jan 3, 2015

xhanin commented Jan 3, 2015

fcamblor commented Jan 3, 2015

xhanin commented Jan 3, 2015

fcamblor commented Jan 4, 2015

xhanin commented Jan 5, 2015

fcamblor commented Jan 22, 2015

@ValidatedFor annotation support for validation groups #137

@ValidatedFor annotation support for validation groups #137

Conversation

fcamblor commented Dec 29, 2014

fcamblor commented Dec 29, 2014

xhanin commented Dec 30, 2014

xhanin commented Dec 30, 2014

fcamblor commented Jan 3, 2015

xhanin commented Jan 3, 2015

fcamblor commented Jan 3, 2015

xhanin commented Jan 3, 2015

fcamblor commented Jan 4, 2015

xhanin commented Jan 5, 2015

fcamblor commented Jan 22, 2015