You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "J. Fiala" <mo...@fwd.at> on 2016/09/03 17:59:11 UTC
Re: CXF3 BeanValidation - wadl2java @Valid
Sergey,
The wadl2java extraarg "-beanValidation" works like a charm, thanks a
lot - now everything I need is a JEE 7 container :).
However, there are some things I have to note:
1.) ValidationExceptionMapper:
Regarding how the ConstraintViolationException is returned with
org.apache.cxf.jaxrs.validation.ValidationExceptionMapper:
I sent an invalid json request to the server.
a) It does respond with 500, but should be 400.
b) The response payload is XML, not json (method has
@Produces({"application/json" }))
Response-Code: 500
Encoding: UTF-8
Content-Type: application/json
Headers: {}
Payload: <ns1:XMLFault
xmlns:ns1="http://cxf.apache.org/bindings/xformat"><ns1:faultstring
xmlns:ns1="http://cxf.apache.org/bindings/xformat">javax.validation.ConstraintViolationException</ns1:faultstring></ns1:XMLFault>
c) It would be nice to have addMessageToResponse flag as
WebApplicationExceptionMapper to get the error details.
2.) Request parameter beanvalidation:
I tried to add @NotNull annotation to a request parameter in the
implementation class (thus trying to work around the missing support of
beanvalidation of wadl2java).
If I add @NotNull to a request parameter in the implementation class,
and fill it in the request, I still get an error 500 with exception in log:
javax.validation.ValidationException: Service Object is null
at
org.apache.cxf.validation.BeanValidationInInterceptor.checkNotNull(BeanValidationInInterceptor.java:49)
~[cxf-core-3.1.6.jar:3.1.6]
It seems as if request parameters are not filled with their values of
the request before the validation is done in BeanValidationInInterceptor.
If I remove the @NotNull-annotation, everything works.
What do you think?
Best regards,
Johannes
Am 29.08.2016 um 22:31 schrieb Sergey Beryozkin:
> I've added a 'beanValidation' option:
>
> https://issues.apache.org/jira/browse/CXF-7032
>
> I'll resolve it once I complete the test
>
> Sergey
> On 29/08/16 11:00, Sergey Beryozkin wrote:
>> On 29/08/16 10:46, Vjacheslav V. Borisov wrote:
>>> 2016-08-27 18:58 GMT+04:00 J. Fiala <mo...@fwd.at>:
>>>
>>>> Sergey,
>>>>
>>>> OK, so there is no option to get query parameter validation for
>>>> wadl2java
>>>> generated java sources in the near future?
>>>>
>>>> So if query parameter validation is desired, one has to switch to
>>>> Swagger
>>>> as contract and generate the BeanValidation-annotations using
>>>> Swagger-Codegen or use code first, right?
>>>>
>>>>
>>> We extensively develop microserices, an rarely need compex query
>>> parameters, this is almost Date or UUID ones in query string
>>> All other data transfered in xml/json payload (which validation is
>>> possible)
>>>
>> Thanks, yes, this is similar to what I was planning to reply with.
>>
>> In the vast majority of cases query/header/cookie parameters are simple
>> properties. Doing the complex mapping from WADL grammar to individual
>> Bean validation properties only for the sake of enforcing some digital
>> or string pattern in such (query) properties and then also making sure
>> it works the other way around (WADL grammar is auto-enhanced based on
>> the avail BeanVal annotations during WADL generatiopn) is not worth it
>> IMHO, especially that it will also overloads WADL grammar.
>>
>> Cheers, Sergey
>>
>
>
Re: CXF3 BeanValidation - wadl2java @Valid
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 05/09/16 17:26, J. Fiala wrote:
> Sergey,
>
> Thanks, I'll check whether the ValidationExceptionMapper is invoked.
>
> The ValidationExceptionMapper currently does not return the
> beanvalidation errors - do you think we can add this using a new flag
> addMessageToResponse to indicate what has gone wrong to the client?
>
Will that expose too many details to the client ? Though I guess it can
make sense if it is done optionally...
> Regarding Request parameter validation for wadl2java-generated sources:
> I have some mandatory parameters and also patterns for query input
> parameters and would like to validate against them. Currently I have to
> rebuild the Request parameters in a separate DTO and validate the
> bean-validation-annotations there manually in each method. This works of
> course, but using annotations in the api directly would be more elegant.
>
OK
> Especially, as CXF3 already supports bean-validation-annotations if I do
> code first.
> It's only not supported if wadl2java is used (for reasons already
> discussed regarding the JAXB processing)...
>
May be introducing a CXF extension, ex:
<wadl:param>
<cxf:beanVal constraint="..."/>
</wadl:param>
might work ?
Sergey
> Best regards,
>
> Johannes
>
>
> Am 04.09.2016 um 18:49 schrieb Sergey Beryozkin:
>> Hi, see comments inline please
>> On 03/09/16 19:00, J. Fiala wrote:
>>> Sergey,
>>>
>>> p.s. If you like I can provide a PR for ValidationExceptionMapper
>>>
>>> Best regards,
>>> Johannes
>>>
>>>
>>> Am 03.09.2016 um 19:59 schrieb J. Fiala:
>>>> Sergey,
>>>>
>>>> The wadl2java extraarg "-beanValidation" works like a charm, thanks a
>>>> lot - now everything I need is a JEE 7 container :).
>>>>
>> Thanks for the check
>>>> However, there are some things I have to note:
>>>>
>>>> 1.) ValidationExceptionMapper:
>>>> Regarding how the ConstraintViolationException is returned with
>>>> org.apache.cxf.jaxrs.validation.ValidationExceptionMapper:
>>>>
>>>> I sent an invalid json request to the server.
>>>>
>>>> a) It does respond with 500, but should be 400.
>>>>
>>>> b) The response payload is XML, not json (method has
>>>> @Produces({"application/json" }))
>>>>
>>>> Response-Code: 500
>>>> Encoding: UTF-8
>>>> Content-Type: application/json
>>>> Headers: {}
>>>> Payload: <ns1:XMLFault
>>>> xmlns:ns1="http://cxf.apache.org/bindings/xformat"><ns1:faultstring
>>>> xmlns:ns1="http://cxf.apache.org/bindings/xformat">javax.validation.ConstraintViolationException</ns1:faultstring></ns1:XMLFault>
>>>>
>>>>
>>>>
>> a) and b) suggest that ValidationExceptionMapper is not invoked - is
>> it registered ?
>> You can validate with the native CXF interceptor or JAX-RS
>> ContainerRequestFilter. if you do the former then the exception
>> escapes into CXF out fault chain and what you see a default response
>> done by the code which is not aware of what JAX-RS is.
>>
>> Can you put a breakpoint in JAXRSDefaultFaultOutInterceptor and see
>> why the mapper is not found (if it has been registered)
>>
>>>> c) It would be nice to have addMessageToResponse flag as
>>>> WebApplicationExceptionMapper to get the error details.
>>>>
>> WebApplicationExceptionMapper can not catch validation exceptions
>>
>>>>
>>>> 2.) Request parameter beanvalidation:
>>>> I tried to add @NotNull annotation to a request parameter in the
>>>> implementation class (thus trying to work around the missing support
>>>> of beanvalidation of wadl2java).
>>>> If I add @NotNull to a request parameter in the implementation class,
>>>> and fill it in the request, I still get an error 500 with exception in
>>>> log:
>>>>
>>>> javax.validation.ValidationException: Service Object is null
>>>> at
>>>> org.apache.cxf.validation.BeanValidationInInterceptor.checkNotNull(BeanValidationInInterceptor.java:49)
>>>>
>>>> ~[cxf-core-3.1.6.jar:3.1.6]
>>>>
>>>> It seems as if request parameters are not filled with their values of
>>>> the request before the validation is done in
>>>> BeanValidationInInterceptor.
>>>> If I remove the @NotNull-annotation, everything works.
>>>>
>> More likely the annotation you have added is ignored because the
>> interface annotations are checked (recall the annotation inheritance
>> thing).
>> I'd not recommend trying to get these NotNull annotations somehow - is
>> it really a problem to check for null in the code ? NotNull for
>> optional parameters (query parameters) seems too strict. It is good to
>> have a service that can default to a certain value if a query is
>> missing or perhaps return NoContent response or may be NotFound if no
>> reasonable default can be allocated - it is better that reporting an
>> 400 (IMHO) if a user forgot to type (or mistyped) a query property
>>
>> Sergey
>>>> What do you think?
>>>>
>>>> Best regards,
>>>> Johannes
>>>>
>>>>
>>>> Am 29.08.2016 um 22:31 schrieb Sergey Beryozkin:
>>>>> I've added a 'beanValidation' option:
>>>>>
>>>>> https://issues.apache.org/jira/browse/CXF-7032
>>>>>
>>>>> I'll resolve it once I complete the test
>>>>>
>>>>> Sergey
>>>>> On 29/08/16 11:00, Sergey Beryozkin wrote:
>>>>>> On 29/08/16 10:46, Vjacheslav V. Borisov wrote:
>>>>>>> 2016-08-27 18:58 GMT+04:00 J. Fiala <mo...@fwd.at>:
>>>>>>>
>>>>>>>> Sergey,
>>>>>>>>
>>>>>>>> OK, so there is no option to get query parameter validation for
>>>>>>>> wadl2java
>>>>>>>> generated java sources in the near future?
>>>>>>>>
>>>>>>>> So if query parameter validation is desired, one has to switch to
>>>>>>>> Swagger
>>>>>>>> as contract and generate the BeanValidation-annotations using
>>>>>>>> Swagger-Codegen or use code first, right?
>>>>>>>>
>>>>>>>>
>>>>>>> We extensively develop microserices, an rarely need compex query
>>>>>>> parameters, this is almost Date or UUID ones in query string
>>>>>>> All other data transfered in xml/json payload (which validation is
>>>>>>> possible)
>>>>>>>
>>>>>> Thanks, yes, this is similar to what I was planning to reply with.
>>>>>>
>>>>>> In the vast majority of cases query/header/cookie parameters are
>>>>>> simple
>>>>>> properties. Doing the complex mapping from WADL grammar to individual
>>>>>> Bean validation properties only for the sake of enforcing some
>>>>>> digital
>>>>>> or string pattern in such (query) properties and then also making
>>>>>> sure
>>>>>> it works the other way around (WADL grammar is auto-enhanced based on
>>>>>> the avail BeanVal annotations during WADL generatiopn) is not
>>>>>> worth it
>>>>>> IMHO, especially that it will also overloads WADL grammar.
>>>>>>
>>>>>> Cheers, Sergey
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: CXF3 BeanValidation - wadl2java @Valid
Posted by "J. Fiala" <mo...@fwd.at>.
Sergey,
Thanks, I'll check whether the ValidationExceptionMapper is invoked.
The ValidationExceptionMapper currently does not return the
beanvalidation errors - do you think we can add this using a new flag
addMessageToResponse to indicate what has gone wrong to the client?
Regarding Request parameter validation for wadl2java-generated sources:
I have some mandatory parameters and also patterns for query input
parameters and would like to validate against them. Currently I have to
rebuild the Request parameters in a separate DTO and validate the
bean-validation-annotations there manually in each method. This works of
course, but using annotations in the api directly would be more elegant.
Especially, as CXF3 already supports bean-validation-annotations if I do
code first.
It's only not supported if wadl2java is used (for reasons already
discussed regarding the JAXB processing)...
Best regards,
Johannes
Am 04.09.2016 um 18:49 schrieb Sergey Beryozkin:
> Hi, see comments inline please
> On 03/09/16 19:00, J. Fiala wrote:
>> Sergey,
>>
>> p.s. If you like I can provide a PR for ValidationExceptionMapper
>>
>> Best regards,
>> Johannes
>>
>>
>> Am 03.09.2016 um 19:59 schrieb J. Fiala:
>>> Sergey,
>>>
>>> The wadl2java extraarg "-beanValidation" works like a charm, thanks a
>>> lot - now everything I need is a JEE 7 container :).
>>>
> Thanks for the check
>>> However, there are some things I have to note:
>>>
>>> 1.) ValidationExceptionMapper:
>>> Regarding how the ConstraintViolationException is returned with
>>> org.apache.cxf.jaxrs.validation.ValidationExceptionMapper:
>>>
>>> I sent an invalid json request to the server.
>>>
>>> a) It does respond with 500, but should be 400.
>>>
>>> b) The response payload is XML, not json (method has
>>> @Produces({"application/json" }))
>>>
>>> Response-Code: 500
>>> Encoding: UTF-8
>>> Content-Type: application/json
>>> Headers: {}
>>> Payload: <ns1:XMLFault
>>> xmlns:ns1="http://cxf.apache.org/bindings/xformat"><ns1:faultstring
>>> xmlns:ns1="http://cxf.apache.org/bindings/xformat">javax.validation.ConstraintViolationException</ns1:faultstring></ns1:XMLFault>
>>>
>>>
>>>
> a) and b) suggest that ValidationExceptionMapper is not invoked - is
> it registered ?
> You can validate with the native CXF interceptor or JAX-RS
> ContainerRequestFilter. if you do the former then the exception
> escapes into CXF out fault chain and what you see a default response
> done by the code which is not aware of what JAX-RS is.
>
> Can you put a breakpoint in JAXRSDefaultFaultOutInterceptor and see
> why the mapper is not found (if it has been registered)
>
>>> c) It would be nice to have addMessageToResponse flag as
>>> WebApplicationExceptionMapper to get the error details.
>>>
> WebApplicationExceptionMapper can not catch validation exceptions
>
>>>
>>> 2.) Request parameter beanvalidation:
>>> I tried to add @NotNull annotation to a request parameter in the
>>> implementation class (thus trying to work around the missing support
>>> of beanvalidation of wadl2java).
>>> If I add @NotNull to a request parameter in the implementation class,
>>> and fill it in the request, I still get an error 500 with exception in
>>> log:
>>>
>>> javax.validation.ValidationException: Service Object is null
>>> at
>>> org.apache.cxf.validation.BeanValidationInInterceptor.checkNotNull(BeanValidationInInterceptor.java:49)
>>>
>>> ~[cxf-core-3.1.6.jar:3.1.6]
>>>
>>> It seems as if request parameters are not filled with their values of
>>> the request before the validation is done in
>>> BeanValidationInInterceptor.
>>> If I remove the @NotNull-annotation, everything works.
>>>
> More likely the annotation you have added is ignored because the
> interface annotations are checked (recall the annotation inheritance
> thing).
> I'd not recommend trying to get these NotNull annotations somehow - is
> it really a problem to check for null in the code ? NotNull for
> optional parameters (query parameters) seems too strict. It is good to
> have a service that can default to a certain value if a query is
> missing or perhaps return NoContent response or may be NotFound if no
> reasonable default can be allocated - it is better that reporting an
> 400 (IMHO) if a user forgot to type (or mistyped) a query property
>
> Sergey
>>> What do you think?
>>>
>>> Best regards,
>>> Johannes
>>>
>>>
>>> Am 29.08.2016 um 22:31 schrieb Sergey Beryozkin:
>>>> I've added a 'beanValidation' option:
>>>>
>>>> https://issues.apache.org/jira/browse/CXF-7032
>>>>
>>>> I'll resolve it once I complete the test
>>>>
>>>> Sergey
>>>> On 29/08/16 11:00, Sergey Beryozkin wrote:
>>>>> On 29/08/16 10:46, Vjacheslav V. Borisov wrote:
>>>>>> 2016-08-27 18:58 GMT+04:00 J. Fiala <mo...@fwd.at>:
>>>>>>
>>>>>>> Sergey,
>>>>>>>
>>>>>>> OK, so there is no option to get query parameter validation for
>>>>>>> wadl2java
>>>>>>> generated java sources in the near future?
>>>>>>>
>>>>>>> So if query parameter validation is desired, one has to switch to
>>>>>>> Swagger
>>>>>>> as contract and generate the BeanValidation-annotations using
>>>>>>> Swagger-Codegen or use code first, right?
>>>>>>>
>>>>>>>
>>>>>> We extensively develop microserices, an rarely need compex query
>>>>>> parameters, this is almost Date or UUID ones in query string
>>>>>> All other data transfered in xml/json payload (which validation is
>>>>>> possible)
>>>>>>
>>>>> Thanks, yes, this is similar to what I was planning to reply with.
>>>>>
>>>>> In the vast majority of cases query/header/cookie parameters are
>>>>> simple
>>>>> properties. Doing the complex mapping from WADL grammar to individual
>>>>> Bean validation properties only for the sake of enforcing some
>>>>> digital
>>>>> or string pattern in such (query) properties and then also making
>>>>> sure
>>>>> it works the other way around (WADL grammar is auto-enhanced based on
>>>>> the avail BeanVal annotations during WADL generatiopn) is not
>>>>> worth it
>>>>> IMHO, especially that it will also overloads WADL grammar.
>>>>>
>>>>> Cheers, Sergey
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
Re: CXF3 BeanValidation - wadl2java @Valid
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi, see comments inline please
On 03/09/16 19:00, J. Fiala wrote:
> Sergey,
>
> p.s. If you like I can provide a PR for ValidationExceptionMapper
>
> Best regards,
> Johannes
>
>
> Am 03.09.2016 um 19:59 schrieb J. Fiala:
>> Sergey,
>>
>> The wadl2java extraarg "-beanValidation" works like a charm, thanks a
>> lot - now everything I need is a JEE 7 container :).
>>
Thanks for the check
>> However, there are some things I have to note:
>>
>> 1.) ValidationExceptionMapper:
>> Regarding how the ConstraintViolationException is returned with
>> org.apache.cxf.jaxrs.validation.ValidationExceptionMapper:
>>
>> I sent an invalid json request to the server.
>>
>> a) It does respond with 500, but should be 400.
>>
>> b) The response payload is XML, not json (method has
>> @Produces({"application/json" }))
>>
>> Response-Code: 500
>> Encoding: UTF-8
>> Content-Type: application/json
>> Headers: {}
>> Payload: <ns1:XMLFault
>> xmlns:ns1="http://cxf.apache.org/bindings/xformat"><ns1:faultstring
>> xmlns:ns1="http://cxf.apache.org/bindings/xformat">javax.validation.ConstraintViolationException</ns1:faultstring></ns1:XMLFault>
>>
>>
a) and b) suggest that ValidationExceptionMapper is not invoked - is it
registered ?
You can validate with the native CXF interceptor or JAX-RS
ContainerRequestFilter. if you do the former then the exception escapes
into CXF out fault chain and what you see a default response done by the
code which is not aware of what JAX-RS is.
Can you put a breakpoint in JAXRSDefaultFaultOutInterceptor and see why
the mapper is not found (if it has been registered)
>> c) It would be nice to have addMessageToResponse flag as
>> WebApplicationExceptionMapper to get the error details.
>>
WebApplicationExceptionMapper can not catch validation exceptions
>>
>> 2.) Request parameter beanvalidation:
>> I tried to add @NotNull annotation to a request parameter in the
>> implementation class (thus trying to work around the missing support
>> of beanvalidation of wadl2java).
>> If I add @NotNull to a request parameter in the implementation class,
>> and fill it in the request, I still get an error 500 with exception in
>> log:
>>
>> javax.validation.ValidationException: Service Object is null
>> at
>> org.apache.cxf.validation.BeanValidationInInterceptor.checkNotNull(BeanValidationInInterceptor.java:49)
>> ~[cxf-core-3.1.6.jar:3.1.6]
>>
>> It seems as if request parameters are not filled with their values of
>> the request before the validation is done in BeanValidationInInterceptor.
>> If I remove the @NotNull-annotation, everything works.
>>
More likely the annotation you have added is ignored because the
interface annotations are checked (recall the annotation inheritance thing).
I'd not recommend trying to get these NotNull annotations somehow - is
it really a problem to check for null in the code ? NotNull for optional
parameters (query parameters) seems too strict. It is good to have a
service that can default to a certain value if a query is missing or
perhaps return NoContent response or may be NotFound if no reasonable
default can be allocated - it is better that reporting an 400 (IMHO) if
a user forgot to type (or mistyped) a query property
Sergey
>> What do you think?
>>
>> Best regards,
>> Johannes
>>
>>
>> Am 29.08.2016 um 22:31 schrieb Sergey Beryozkin:
>>> I've added a 'beanValidation' option:
>>>
>>> https://issues.apache.org/jira/browse/CXF-7032
>>>
>>> I'll resolve it once I complete the test
>>>
>>> Sergey
>>> On 29/08/16 11:00, Sergey Beryozkin wrote:
>>>> On 29/08/16 10:46, Vjacheslav V. Borisov wrote:
>>>>> 2016-08-27 18:58 GMT+04:00 J. Fiala <mo...@fwd.at>:
>>>>>
>>>>>> Sergey,
>>>>>>
>>>>>> OK, so there is no option to get query parameter validation for
>>>>>> wadl2java
>>>>>> generated java sources in the near future?
>>>>>>
>>>>>> So if query parameter validation is desired, one has to switch to
>>>>>> Swagger
>>>>>> as contract and generate the BeanValidation-annotations using
>>>>>> Swagger-Codegen or use code first, right?
>>>>>>
>>>>>>
>>>>> We extensively develop microserices, an rarely need compex query
>>>>> parameters, this is almost Date or UUID ones in query string
>>>>> All other data transfered in xml/json payload (which validation is
>>>>> possible)
>>>>>
>>>> Thanks, yes, this is similar to what I was planning to reply with.
>>>>
>>>> In the vast majority of cases query/header/cookie parameters are simple
>>>> properties. Doing the complex mapping from WADL grammar to individual
>>>> Bean validation properties only for the sake of enforcing some digital
>>>> or string pattern in such (query) properties and then also making sure
>>>> it works the other way around (WADL grammar is auto-enhanced based on
>>>> the avail BeanVal annotations during WADL generatiopn) is not worth it
>>>> IMHO, especially that it will also overloads WADL grammar.
>>>>
>>>> Cheers, Sergey
>>>>
>>>
>>>
>>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: CXF3 BeanValidation - wadl2java @Valid
Posted by "J. Fiala" <mo...@fwd.at>.
Sergey,
p.s. If you like I can provide a PR for ValidationExceptionMapper
Best regards,
Johannes
Am 03.09.2016 um 19:59 schrieb J. Fiala:
> Sergey,
>
> The wadl2java extraarg "-beanValidation" works like a charm, thanks a
> lot - now everything I need is a JEE 7 container :).
>
> However, there are some things I have to note:
>
> 1.) ValidationExceptionMapper:
> Regarding how the ConstraintViolationException is returned with
> org.apache.cxf.jaxrs.validation.ValidationExceptionMapper:
>
> I sent an invalid json request to the server.
>
> a) It does respond with 500, but should be 400.
>
> b) The response payload is XML, not json (method has
> @Produces({"application/json" }))
>
> Response-Code: 500
> Encoding: UTF-8
> Content-Type: application/json
> Headers: {}
> Payload: <ns1:XMLFault
> xmlns:ns1="http://cxf.apache.org/bindings/xformat"><ns1:faultstring
> xmlns:ns1="http://cxf.apache.org/bindings/xformat">javax.validation.ConstraintViolationException</ns1:faultstring></ns1:XMLFault>
>
>
> c) It would be nice to have addMessageToResponse flag as
> WebApplicationExceptionMapper to get the error details.
>
>
> 2.) Request parameter beanvalidation:
> I tried to add @NotNull annotation to a request parameter in the
> implementation class (thus trying to work around the missing support
> of beanvalidation of wadl2java).
> If I add @NotNull to a request parameter in the implementation class,
> and fill it in the request, I still get an error 500 with exception in
> log:
>
> javax.validation.ValidationException: Service Object is null
> at
> org.apache.cxf.validation.BeanValidationInInterceptor.checkNotNull(BeanValidationInInterceptor.java:49)
> ~[cxf-core-3.1.6.jar:3.1.6]
>
> It seems as if request parameters are not filled with their values of
> the request before the validation is done in BeanValidationInInterceptor.
> If I remove the @NotNull-annotation, everything works.
>
> What do you think?
>
> Best regards,
> Johannes
>
>
> Am 29.08.2016 um 22:31 schrieb Sergey Beryozkin:
>> I've added a 'beanValidation' option:
>>
>> https://issues.apache.org/jira/browse/CXF-7032
>>
>> I'll resolve it once I complete the test
>>
>> Sergey
>> On 29/08/16 11:00, Sergey Beryozkin wrote:
>>> On 29/08/16 10:46, Vjacheslav V. Borisov wrote:
>>>> 2016-08-27 18:58 GMT+04:00 J. Fiala <mo...@fwd.at>:
>>>>
>>>>> Sergey,
>>>>>
>>>>> OK, so there is no option to get query parameter validation for
>>>>> wadl2java
>>>>> generated java sources in the near future?
>>>>>
>>>>> So if query parameter validation is desired, one has to switch to
>>>>> Swagger
>>>>> as contract and generate the BeanValidation-annotations using
>>>>> Swagger-Codegen or use code first, right?
>>>>>
>>>>>
>>>> We extensively develop microserices, an rarely need compex query
>>>> parameters, this is almost Date or UUID ones in query string
>>>> All other data transfered in xml/json payload (which validation is
>>>> possible)
>>>>
>>> Thanks, yes, this is similar to what I was planning to reply with.
>>>
>>> In the vast majority of cases query/header/cookie parameters are simple
>>> properties. Doing the complex mapping from WADL grammar to individual
>>> Bean validation properties only for the sake of enforcing some digital
>>> or string pattern in such (query) properties and then also making sure
>>> it works the other way around (WADL grammar is auto-enhanced based on
>>> the avail BeanVal annotations during WADL generatiopn) is not worth it
>>> IMHO, especially that it will also overloads WADL grammar.
>>>
>>> Cheers, Sergey
>>>
>>
>>
>
>