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/08 07:41:24 UTC
Re: WadlGenerator - Bean validation support for complex types?
Hi Sergey,
The point of the extension I did for the WadlGenerator (to add
simpletype restrictions to query parameters based on their
beanvalidation annotations - seee
https://github.com/apache/cxf/pull/146/files, WadlGenerator.java) is to
support developers who have an existing codebase with lots of
BeanValidation annotations already annotated in the method parameters.
If they want to move these into a WADL contract it is really easy to
expose them first using the WadlGenerator and then pick the simpletype
restrictions and move them out to schema. If you don't have these in the
generated WADL, you have to do this from the code which is much more
work, doing this in the WADL only is much more fun.
After this is done and the WADL is fine, of course they can switch to
use the contract WADL and expose this instead of the generated WADL
(this feature works great including all schema references, I've used it
with such a fine-tuned WADL, really nice and no work at all, maybe we
could enhance the documentation there that it is working immediately for
schema references as well without any additional configuration work -
see http://cxf.apache.org/docs/jaxrs-services-description.html,
currently it is a bit misleading because I initially thought I have to
set WadlGenerator.schemaLocations to use embedded schemas, but this is
actually not the case if schema include is used instead of xs:import!).
Of course I can also add a switch to turn this off if someone really
doesn't like it, but I think this will be rarely the case.
Best regards,
Johannes
Am 18.08.2016 um 13:19 schrieb Sergey Beryozkin:
> Hi
>
> thanks for the explanation.
>
> On 18/08/16 11:57, J. Fiala wrote:
>> Hi,
>>
>> If I'm using BeanValidation-annotations in my model classes, they are
>> not picked up by the WADLGenerator and so are lost if I do code first
>> and I have to look them up and model them in the WADL manually.
>>
>> At least @NotNull support would be nice, because this is really easy to
>> do (see the PR).
>>
> WADLGenerator will set a required flag if it is 'int'/'boolean' as
> opposed to Boolean/Integer
>
>> The others are a bit more tricky as they have to be generated as inline
>> simpletypes and probably in the WADL would be replaced by existing
>> simpletypes in the WADL/schema, but at least the developer has the hint
>> there is a pattern/restriction in place.
>> I already implemented @Size/@Min/@Max/@Pattern so you just have to pull
>> it in.
> I'd rather prefer to avoid going into all these schema manipulations.
> These hints can me made available in WADL grammar directly - have you
> checked if JAXB annotations can be used to set some of those
> restrictions ? Another option: WADL generator can be configured with a
> prepared XML schema as opposed to generating it.
>>
>> So better support for the BeanValidation annotations makes code first a
>> lot easier and also extending an existing WADL using code first for new
>> model classes...
> thanks, Sergey
>>
>> Best regards,
>>
>> Johannes
>>
>>
>> Am 18.08.2016 um 00:29 schrieb Sergey Beryozkin:
>>> Hi
>>>
>>> Can you explain please what exactly the purpose of it can be ?
>>> WADL generator simply reports the model info by using a JAXB compiler
>>> to generate XML schema, I'm trying to figure out how does the bean
>>> validation can help here or what it can change
>>>
>>> Sergey
>>> On 17/08/16 18:18, J. Fiala wrote:
>>>> I added this PR for bean-validation-support for query parameters:
>>>> https://github.com/apache/cxf/pull/146
>>>>
>>>> This also adds the required-flag for params by supporting @NotNull
>>>> (see
>>>> related question here:
>>>> http://stackoverflow.com/questions/13968261/required-queryparam-in-jax-rs-and-what-to-do-in-their-absence).
>>>>
>>>>
>>>>
>>>>
>>>> Additionally the PR adds support for @Size, @Min/@Max and @Pattern to
>>>> the query parameters and will add the proper restrictions inline:
>>>>
>>>> * @NotNull - minOccurs="1"
>>>>
>>>> * @Size - "<xs:minLengthvalue = " + size.min() + "/>",
>>>> "<xs:maxLengthvalue = " + size.max() + "/>"
>>>>
>>>> * @Min - "<xs:minInclusive value = " + min.value() + "/>"
>>>>
>>>> * @Min - "<xs:maxInclusive value = " + max.value() + "/>"
>>>>
>>>> * @Pattern - <xs:pattern value=" + pattern.regexp() + " />"
>>>>
>>>> For adding bean-validation-support to the complex types the JAXB
>>>> processing / schema has to be parsed/filtered.
>>>>
>>>> The Java to schema mappings seems to be done here in
>>>> WadlGenerator.java,
>>>> line 1541:
>>>> for (DOMResult r : JAXBUtils.generateJaxbSchemas(context,
>>>> CastUtils.cast(Collections.emptyMap(),
>>>> String.class,
>>>> DOMResult.class))) {
>>>>
>>>> Am I correct in assuming we need a JAXB adapter which picks up the
>>>> beanvalidation-annotations?
>>>> https://docs.oracle.com/cd/E19316-01/819-3669/bnbdf/index.html
>>>>
>>>> So it seems we need to prepare the proper XmlAdapters
>>>> (https://docs.oracle.com/javase/7/docs/api/javax/xml/bind/annotation/adapters/XmlAdapter.html)
>>>>
>>>>
>>>> to generate the necessary restrictions in the schema.
>>>>
>>>> However, it would also be nice to also add proper SimpleTypes and
>>>> reference them from the complexTypes (e.g. simpleType string_50 for a
>>>> string with a maximum of 50).
>>>>
>>>> Best regards,
>>>>
>>>> Johannes
>>>>
>>>>
>>>
>>>
>>
>
>
Re: WadlGenerator - Bean validation support for complex types?
Posted by "J. Fiala" <mo...@fwd.at>.
Hi,
No problem, all I need is a quick confirmation if you like the solution,
then I can extend it to support more nested restrictions and polish
everything up (I'd suggest moving all the beanvalidation methods into a
separate utiltiy class).
After SourceGenerator is fine, I can take a look at the WadlGenerator and
try to generate the parameter restrictions into a separate grammar.
Yes, it's great the talk has been accepted, looking forward to meet you in
Seville!
Best regards,
Johannes
--
View this message in context: http://cxf.547215.n5.nabble.com/WadlGenerator-Bean-validation-support-for-complex-types-tp5771709p5773185.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WadlGenerator - Bean validation support for complex types?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
I'm sorry have not had much time to look into recently, being a bit
overwhelmed with the various tasks. I'll try to look deeper into it in a
week's time, I'll be on and off next week.
I saw your presentation being scheduled for Apache Con EU 2016, great,
may we we can also discuss few details there :-)
Cheers, Sergey
On 30/09/16 14:08, J. Fiala wrote:
> Sergey,
>
> Pls let me know what you think of my addition to the SourceGenerator.java
> (https://github.com/apache/cxf/pull/146/files), then I can add support for
> the other BeanValidation annotations and polish things up (maybe extract the
> whole BeanValidation into a separate utility class?).
>
> Best regards,
> Johannes
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/WadlGenerator-Bean-validation-support-for-complex-types-tp5771709p5773183.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: WadlGenerator - Bean validation support for complex types?
Posted by "J. Fiala" <mo...@fwd.at>.
Sergey,
Pls let me know what you think of my addition to the SourceGenerator.java
(https://github.com/apache/cxf/pull/146/files), then I can add support for
the other BeanValidation annotations and polish things up (maybe extract the
whole BeanValidation into a separate utility class?).
Best regards,
Johannes
--
View this message in context: http://cxf.547215.n5.nabble.com/WadlGenerator-Bean-validation-support-for-complex-types-tp5771709p5773183.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WadlGenerator - Bean validation support for complex types?
Posted by "J. Fiala" <mo...@fwd.at>.
Sergey,
Thanks for the hint - now I added the schema type reference detection
for minLength/maxLength/pattern as example in SourceGenerator.java.
I had to add a separate method to get all prefixes used in the WADL
(createWadlPrefixMap(app)), as schemaCollections doesn't hold them
(schemaCollection.getNamespaceContext().getDeclaredPrefixes().getLength()
is 0).
Can you take a look if you like it - if yes I'll add the other ones?
For WadlGenerator I'd then suggest to automatically setup a separate
parameter-beanvalidation schema which could contain the complete
collection of all beanvalidations used with generated schemaType-names.
Then it we could remove the inline simple types from
SourceGenerator.java as well if you don't want to support it.
Best regards,
Johannes
Am 12.09.2016 um 12:10 schrieb Sergey Beryozkin:
> Johannes,
>
> FYI, SourceGenerator keeps a SchemaCollection field - so knowing a
> parameter type reference (SourceGenerator has a utility method for
> giving you a full QName of this reference) you can load an appropriate
> XML Schema type.
>
> I'm still thinking going a ParamConverter path is significantly simpler.
> But please experiment, SourceGenerator does not enforce that
> parameters should not refer to the grammar...
>
> Cheers, Sergey
>
> On 11/09/16 21:44, Sergey Beryozkin wrote:
>> Swagger JAX-RS is capable of generating Swagger JSON based on JAX-RS
>> annotations alone. Having partial schema fragment inside WADL param is
>> not good IMHO.
>>
>> If you'd like to explore it further - do assume that parameters will
>> refer to XML Schema in WADL:grammar. WADL has XMLSchema loaded - so you
>> can use that data to analyze the types and add BeanVal annotations if
>> -beanValidation is enabled, using full class names of these annotations
>> without introducing a strong beanVal API dep
>>
>> Many thanks, Sergey
>>
>>
>> On 11/09/16 10:00, J. Fiala wrote:
>>> Sergey,
>>>
>>> I think we can use the simpletype restrictions as already
>>> implemented in
>>> WadlGenerator and even use them in the SourceGenerator (wadl2java).
>>>
>>> I implemented a draft for Size(min,max) and Pattern, can you take a
>>> look
>>> in the PR (see SourceGenerator.java)?
>>>
>>> https://github.com/apache/cxf/pull/146
>>>
>>> If you like it, I'll add the other annotations.
>>> This allows usage of standard schema simpletypes and still get the
>>> beanvalidation annotations (without the need to use cxf:beanVal).
>>>
>>> The only thing missing is usage of the types in a separate schema, but
>>> that can be added later when access to the simpletypes is possible
>>> during the parameter processing.
>>>
>>> Best regards,
>>> Johannes
>>>
>>>
>>>
>>> Am 10.09.2016 um 21:41 schrieb J. Fiala:
>>>> Sergey,
>>>>
>>>> 1.) So we would have to map the complex types to the parameter list
>>>> here.
>>>> I don't think this is a really good idea, I think the parameters
>>>> should always map to simpletypes.
>>>>
>>>> 2.) I think the cxf:beanVal extension is a good starting point for now
>>>> (as long as we don't get access to the types/restrictions backing the
>>>> parameters in the schema).
>>>> I think it would be readable and later can be easily ported to a type.
>>>> The only sad thing is that one has to define it for each parameter,
>>>> but we could also allow to define types maybe?.
>>>>
>>>> a) The easiest solution (add all restrictions to the parameter
>>>> directly):
>>>> <!-- required can be easily picked from @NotNull --->
>>>> <wadl:param name="..." required="true" type="xs:string">
>>>> <cxf:beanValRestriction pattern="..." minLength="...."
>>>> maxLength="..." />
>>>> </wadl:param>
>>>>
>>>> <wadl:param name="..." required="true" type="xs:integer">
>>>> <cxf:beanValRestriction pattern="..." minInclusive="...."
>>>> maxInclusive="..." />
>>>> </wadl:param>\u2026
>>>>
>>>> b) Also allow usage of types (I believe much better):
>>>>
>>>> <wadl:param name="..." required="true"
>>>> type="xs:integer"><cxf:beanValRestriction type="mytype"
>>>> /></wadl:param>\u2026
>>>> <cxf:type name="mytype" pattern="..." minLength=".."
>>>> maxLength="..." />
>>>>
>>>> This way it would be possible to use search/replace once in the future
>>>> we are able to access the restrictions of the parameters!
>>>>
>>>> Regarding WadlGenerator: Here we could reuse this perfectly, simply
>>>> generate the appropriate cxf:beanValidationRestrictions (see 1.) the
>>>> easy way).
>>>>
>>>> So we have both code first/contract first covered with a solution
>>>> which is easy to use and also supports existing codebases with
>>>> BeanValidation-annotations.
>>>>
>>>> What do you think?
>>>>
>>>> Best regards,
>>>> Johannes
>>>>
>>>>
>>>> Am 08.09.2016 um 11:42 schrieb Sergey Beryozkin:
>>>>> Hi Johannes
>>>>>
>>>>> I suppose an idea which you have tried to do with enriching wadl:doc
>>>>> is useful - lets keep it in mind.
>>>>>
>>>>> So these ideas are proposed:
>>>>>
>>>>> 1. in WADL-first one simply has the query/header/path parameters
>>>>> referring to WADL grammar complex types - this will produce Java
>>>>> types
>>>>> with BeanVal annotations - and will require JAX-RS ParamConverters
>>>>> to to create these beans from Strings.
>>>>> Can you experiment with this option ? Bean val can then be done
>>>>> inside this param converter or with JAXRS BeanVal filer (or may be
>>>>> invoker).
>>>>>
>>>>> Nothing extra will need to be done on a source generator side for
>>>>> this to work.
>>>>>
>>>>> If this option works for WADL-first - then you can start thinking of
>>>>> how to make it work in the WADL-gen case - WADLGen may simply need to
>>>>> be enhanced to optionally add non-body JAX-RS parameter types to a
>>>>> JAXB context passed to JAXB schema compiler.
>>>>>
>>>>> 2. Introduce a cxf:beanVal extension which may be added to wadl:doc ?
>>>>>
>>>>> Sergey
>>>>>
>>>>>
>>>>>
>>>>> On 08/09/16 10:22, J. Fiala wrote:
>>>>>> Hi Sergey,
>>>>>>
>>>>>> No problem, the solution you suggested is of course the better way
>>>>>> regarding interoperability!
>>>>>>
>>>>>> (and great if it will work both ways eventually...!!)
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Johannes
>>>>>>
>>>>>>
>>>>>> Am 08.09.2016 um 11:11 schrieb Sergey Beryozkin:
>>>>>>> Hi Johannes
>>>>>>>
>>>>>>> I'm sorry but I'm not seeing how this can be applied - you generate
>>>>>>> some schema types inside wadl:doc - it will never have a chance of
>>>>>>> any
>>>>>>> interoperability (non CXF wadl-to-java processing it) and looks
>>>>>>> like a
>>>>>>> 'perfect' hack :-) - I do appreciate your effort, thanks for that,
>>>>>>> but
>>>>>>> I'm not going to apply it.
>>>>>>>
>>>>>>> In the other thread we are discussing how starting from a WADL can
>>>>>>> somehow get Query (and indeed header/path) being BeanVal validated.
>>>>>>> The solution needs to work both ways. I.e - if we settle on the
>>>>>>> idea
>>>>>>> that a wadl:param refers to a complex grammar type then at least I
>>>>>>> can
>>>>>>> imagine that in a Java to WADL case somehow a Java class with Bean
>>>>>>> validations can be projected back into the grammar
>>>>>>>
>>>>>>> Cheers, Sergey
>>>>>>>
>>>>>>> On 08/09/16 08:41, J. Fiala wrote:
>>>>>>>> Hi Sergey,
>>>>>>>>
>>>>>>>> The point of the extension I did for the WadlGenerator (to add
>>>>>>>> simpletype restrictions to query parameters based on their
>>>>>>>> beanvalidation annotations - seee
>>>>>>>> https://github.com/apache/cxf/pull/146/files, WadlGenerator.java)
>>>>>>>> is to
>>>>>>>> support developers who have an existing codebase with lots of
>>>>>>>> BeanValidation annotations already annotated in the method
>>>>>>>> parameters.
>>>>>>>>
>>>>>>>> If they want to move these into a WADL contract it is really
>>>>>>>> easy to
>>>>>>>> expose them first using the WadlGenerator and then pick the
>>>>>>>> simpletype
>>>>>>>> restrictions and move them out to schema. If you don't have these
>>>>>>>> in the
>>>>>>>> generated WADL, you have to do this from the code which is much
>>>>>>>> more
>>>>>>>> work, doing this in the WADL only is much more fun.
>>>>>>>>
>>>>>>>> After this is done and the WADL is fine, of course they can
>>>>>>>> switch to
>>>>>>>> use the contract WADL and expose this instead of the generated
>>>>>>>> WADL
>>>>>>>> (this feature works great including all schema references, I've
>>>>>>>> used it
>>>>>>>> with such a fine-tuned WADL, really nice and no work at all,
>>>>>>>> maybe we
>>>>>>>> could enhance the documentation there that it is working
>>>>>>>> immediately for
>>>>>>>> schema references as well without any additional configuration
>>>>>>>> work -
>>>>>>>> see http://cxf.apache.org/docs/jaxrs-services-description.html,
>>>>>>>> currently it is a bit misleading because I initially thought I
>>>>>>>> have to
>>>>>>>> set WadlGenerator.schemaLocations to use embedded schemas, but
>>>>>>>> this is
>>>>>>>> actually not the case if schema include is used instead of
>>>>>>>> xs:import!).
>>>>>>>>
>>>>>>>> Of course I can also add a switch to turn this off if someone
>>>>>>>> really
>>>>>>>> doesn't like it, but I think this will be rarely the case.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Johannes
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 18.08.2016 um 13:19 schrieb Sergey Beryozkin:
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> thanks for the explanation.
>>>>>>>>>
>>>>>>>>> On 18/08/16 11:57, J. Fiala wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> If I'm using BeanValidation-annotations in my model classes,
>>>>>>>>>> they are
>>>>>>>>>> not picked up by the WADLGenerator and so are lost if I do code
>>>>>>>>>> first
>>>>>>>>>> and I have to look them up and model them in the WADL manually.
>>>>>>>>>>
>>>>>>>>>> At least @NotNull support would be nice, because this is really
>>>>>>>>>> easy to
>>>>>>>>>> do (see the PR).
>>>>>>>>>>
>>>>>>>>> WADLGenerator will set a required flag if it is
>>>>>>>>> 'int'/'boolean' as
>>>>>>>>> opposed to Boolean/Integer
>>>>>>>>>
>>>>>>>>>> The others are a bit more tricky as they have to be generated as
>>>>>>>>>> inline
>>>>>>>>>> simpletypes and probably in the WADL would be replaced by
>>>>>>>>>> existing
>>>>>>>>>> simpletypes in the WADL/schema, but at least the developer
>>>>>>>>>> has the
>>>>>>>>>> hint
>>>>>>>>>> there is a pattern/restriction in place.
>>>>>>>>>> I already implemented @Size/@Min/@Max/@Pattern so you just
>>>>>>>>>> have to
>>>>>>>>>> pull
>>>>>>>>>> it in.
>>>>>>>>> I'd rather prefer to avoid going into all these schema
>>>>>>>>> manipulations.
>>>>>>>>> These hints can me made available in WADL grammar directly - have
>>>>>>>>> you
>>>>>>>>> checked if JAXB annotations can be used to set some of those
>>>>>>>>> restrictions ? Another option: WADL generator can be configured
>>>>>>>>> with a
>>>>>>>>> prepared XML schema as opposed to generating it.
>>>>>>>>>>
>>>>>>>>>> So better support for the BeanValidation annotations makes code
>>>>>>>>>> first a
>>>>>>>>>> lot easier and also extending an existing WADL using code first
>>>>>>>>>> for
>>>>>>>>>> new
>>>>>>>>>> model classes...
>>>>>>>>> thanks, Sergey
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>
>>>>>>>>>> Johannes
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Am 18.08.2016 um 00:29 schrieb Sergey Beryozkin:
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> Can you explain please what exactly the purpose of it can be ?
>>>>>>>>>>> WADL generator simply reports the model info by using a JAXB
>>>>>>>>>>> compiler
>>>>>>>>>>> to generate XML schema, I'm trying to figure out how does the
>>>>>>>>>>> bean
>>>>>>>>>>> validation can help here or what it can change
>>>>>>>>>>>
>>>>>>>>>>> Sergey
>>>>>>>>>>> On 17/08/16 18:18, J. Fiala wrote:
>>>>>>>>>>>> I added this PR for bean-validation-support for query
>>>>>>>>>>>> parameters:
>>>>>>>>>>>> https://github.com/apache/cxf/pull/146
>>>>>>>>>>>>
>>>>>>>>>>>> This also adds the required-flag for params by supporting
>>>>>>>>>>>> @NotNull
>>>>>>>>>>>> (see
>>>>>>>>>>>> related question here:
>>>>>>>>>>>> http://stackoverflow.com/questions/13968261/required-queryparam-in-jax-rs-and-what-to-do-in-their-absence).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Additionally the PR adds support for @Size, @Min/@Max and
>>>>>>>>>>>> @Pattern to
>>>>>>>>>>>> the query parameters and will add the proper restrictions
>>>>>>>>>>>> inline:
>>>>>>>>>>>>
>>>>>>>>>>>> * @NotNull - minOccurs="1"
>>>>>>>>>>>>
>>>>>>>>>>>> * @Size - "<xs:minLengthvalue = " + size.min() + "/>",
>>>>>>>>>>>> "<xs:maxLengthvalue = " + size.max() + "/>"
>>>>>>>>>>>>
>>>>>>>>>>>> * @Min - "<xs:minInclusive value = " + min.value() + "/>"
>>>>>>>>>>>>
>>>>>>>>>>>> * @Min - "<xs:maxInclusive value = " + max.value() + "/>"
>>>>>>>>>>>>
>>>>>>>>>>>> * @Pattern - <xs:pattern value=" + pattern.regexp() + " />"
>>>>>>>>>>>>
>>>>>>>>>>>> For adding bean-validation-support to the complex types the
>>>>>>>>>>>> JAXB
>>>>>>>>>>>> processing / schema has to be parsed/filtered.
>>>>>>>>>>>>
>>>>>>>>>>>> The Java to schema mappings seems to be done here in
>>>>>>>>>>>> WadlGenerator.java,
>>>>>>>>>>>> line 1541:
>>>>>>>>>>>> for (DOMResult r : JAXBUtils.generateJaxbSchemas(context,
>>>>>>>>>>>> CastUtils.cast(Collections.emptyMap(),
>>>>>>>>>>>> String.class,
>>>>>>>>>>>> DOMResult.class))) {
>>>>>>>>>>>>
>>>>>>>>>>>> Am I correct in assuming we need a JAXB adapter which picks up
>>>>>>>>>>>> the
>>>>>>>>>>>> beanvalidation-annotations?
>>>>>>>>>>>> https://docs.oracle.com/cd/E19316-01/819-3669/bnbdf/index.html
>>>>>>>>>>>>
>>>>>>>>>>>> So it seems we need to prepare the proper XmlAdapters
>>>>>>>>>>>> (https://docs.oracle.com/javase/7/docs/api/javax/xml/bind/annotation/adapters/XmlAdapter.html)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> to generate the necessary restrictions in the schema.
>>>>>>>>>>>>
>>>>>>>>>>>> However, it would also be nice to also add proper SimpleTypes
>>>>>>>>>>>> and
>>>>>>>>>>>> reference them from the complexTypes (e.g. simpleType
>>>>>>>>>>>> string_50
>>>>>>>>>>>> for a
>>>>>>>>>>>> string with a maximum of 50).
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Johannes
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>
Re: WadlGenerator - Bean validation support for complex types?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Johannes,
FYI, SourceGenerator keeps a SchemaCollection field - so knowing a
parameter type reference (SourceGenerator has a utility method for
giving you a full QName of this reference) you can load an appropriate
XML Schema type.
I'm still thinking going a ParamConverter path is significantly simpler.
But please experiment, SourceGenerator does not enforce that parameters
should not refer to the grammar...
Cheers, Sergey
On 11/09/16 21:44, Sergey Beryozkin wrote:
> Swagger JAX-RS is capable of generating Swagger JSON based on JAX-RS
> annotations alone. Having partial schema fragment inside WADL param is
> not good IMHO.
>
> If you'd like to explore it further - do assume that parameters will
> refer to XML Schema in WADL:grammar. WADL has XMLSchema loaded - so you
> can use that data to analyze the types and add BeanVal annotations if
> -beanValidation is enabled, using full class names of these annotations
> without introducing a strong beanVal API dep
>
> Many thanks, Sergey
>
>
> On 11/09/16 10:00, J. Fiala wrote:
>> Sergey,
>>
>> I think we can use the simpletype restrictions as already implemented in
>> WadlGenerator and even use them in the SourceGenerator (wadl2java).
>>
>> I implemented a draft for Size(min,max) and Pattern, can you take a look
>> in the PR (see SourceGenerator.java)?
>>
>> https://github.com/apache/cxf/pull/146
>>
>> If you like it, I'll add the other annotations.
>> This allows usage of standard schema simpletypes and still get the
>> beanvalidation annotations (without the need to use cxf:beanVal).
>>
>> The only thing missing is usage of the types in a separate schema, but
>> that can be added later when access to the simpletypes is possible
>> during the parameter processing.
>>
>> Best regards,
>> Johannes
>>
>>
>>
>> Am 10.09.2016 um 21:41 schrieb J. Fiala:
>>> Sergey,
>>>
>>> 1.) So we would have to map the complex types to the parameter list
>>> here.
>>> I don't think this is a really good idea, I think the parameters
>>> should always map to simpletypes.
>>>
>>> 2.) I think the cxf:beanVal extension is a good starting point for now
>>> (as long as we don't get access to the types/restrictions backing the
>>> parameters in the schema).
>>> I think it would be readable and later can be easily ported to a type.
>>> The only sad thing is that one has to define it for each parameter,
>>> but we could also allow to define types maybe?.
>>>
>>> a) The easiest solution (add all restrictions to the parameter
>>> directly):
>>> <!-- required can be easily picked from @NotNull --->
>>> <wadl:param name="..." required="true" type="xs:string">
>>> <cxf:beanValRestriction pattern="..." minLength="...."
>>> maxLength="..." />
>>> </wadl:param>
>>>
>>> <wadl:param name="..." required="true" type="xs:integer">
>>> <cxf:beanValRestriction pattern="..." minInclusive="...."
>>> maxInclusive="..." />
>>> </wadl:param>\u2026
>>>
>>> b) Also allow usage of types (I believe much better):
>>>
>>> <wadl:param name="..." required="true"
>>> type="xs:integer"><cxf:beanValRestriction type="mytype" /></wadl:param>\u2026
>>> <cxf:type name="mytype" pattern="..." minLength=".." maxLength="..." />
>>>
>>> This way it would be possible to use search/replace once in the future
>>> we are able to access the restrictions of the parameters!
>>>
>>> Regarding WadlGenerator: Here we could reuse this perfectly, simply
>>> generate the appropriate cxf:beanValidationRestrictions (see 1.) the
>>> easy way).
>>>
>>> So we have both code first/contract first covered with a solution
>>> which is easy to use and also supports existing codebases with
>>> BeanValidation-annotations.
>>>
>>> What do you think?
>>>
>>> Best regards,
>>> Johannes
>>>
>>>
>>> Am 08.09.2016 um 11:42 schrieb Sergey Beryozkin:
>>>> Hi Johannes
>>>>
>>>> I suppose an idea which you have tried to do with enriching wadl:doc
>>>> is useful - lets keep it in mind.
>>>>
>>>> So these ideas are proposed:
>>>>
>>>> 1. in WADL-first one simply has the query/header/path parameters
>>>> referring to WADL grammar complex types - this will produce Java types
>>>> with BeanVal annotations - and will require JAX-RS ParamConverters
>>>> to to create these beans from Strings.
>>>> Can you experiment with this option ? Bean val can then be done
>>>> inside this param converter or with JAXRS BeanVal filer (or may be
>>>> invoker).
>>>>
>>>> Nothing extra will need to be done on a source generator side for
>>>> this to work.
>>>>
>>>> If this option works for WADL-first - then you can start thinking of
>>>> how to make it work in the WADL-gen case - WADLGen may simply need to
>>>> be enhanced to optionally add non-body JAX-RS parameter types to a
>>>> JAXB context passed to JAXB schema compiler.
>>>>
>>>> 2. Introduce a cxf:beanVal extension which may be added to wadl:doc ?
>>>>
>>>> Sergey
>>>>
>>>>
>>>>
>>>> On 08/09/16 10:22, J. Fiala wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> No problem, the solution you suggested is of course the better way
>>>>> regarding interoperability!
>>>>>
>>>>> (and great if it will work both ways eventually...!!)
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Johannes
>>>>>
>>>>>
>>>>> Am 08.09.2016 um 11:11 schrieb Sergey Beryozkin:
>>>>>> Hi Johannes
>>>>>>
>>>>>> I'm sorry but I'm not seeing how this can be applied - you generate
>>>>>> some schema types inside wadl:doc - it will never have a chance of
>>>>>> any
>>>>>> interoperability (non CXF wadl-to-java processing it) and looks
>>>>>> like a
>>>>>> 'perfect' hack :-) - I do appreciate your effort, thanks for that,
>>>>>> but
>>>>>> I'm not going to apply it.
>>>>>>
>>>>>> In the other thread we are discussing how starting from a WADL can
>>>>>> somehow get Query (and indeed header/path) being BeanVal validated.
>>>>>> The solution needs to work both ways. I.e - if we settle on the idea
>>>>>> that a wadl:param refers to a complex grammar type then at least I
>>>>>> can
>>>>>> imagine that in a Java to WADL case somehow a Java class with Bean
>>>>>> validations can be projected back into the grammar
>>>>>>
>>>>>> Cheers, Sergey
>>>>>>
>>>>>> On 08/09/16 08:41, J. Fiala wrote:
>>>>>>> Hi Sergey,
>>>>>>>
>>>>>>> The point of the extension I did for the WadlGenerator (to add
>>>>>>> simpletype restrictions to query parameters based on their
>>>>>>> beanvalidation annotations - seee
>>>>>>> https://github.com/apache/cxf/pull/146/files, WadlGenerator.java)
>>>>>>> is to
>>>>>>> support developers who have an existing codebase with lots of
>>>>>>> BeanValidation annotations already annotated in the method
>>>>>>> parameters.
>>>>>>>
>>>>>>> If they want to move these into a WADL contract it is really easy to
>>>>>>> expose them first using the WadlGenerator and then pick the
>>>>>>> simpletype
>>>>>>> restrictions and move them out to schema. If you don't have these
>>>>>>> in the
>>>>>>> generated WADL, you have to do this from the code which is much
>>>>>>> more
>>>>>>> work, doing this in the WADL only is much more fun.
>>>>>>>
>>>>>>> After this is done and the WADL is fine, of course they can
>>>>>>> switch to
>>>>>>> use the contract WADL and expose this instead of the generated WADL
>>>>>>> (this feature works great including all schema references, I've
>>>>>>> used it
>>>>>>> with such a fine-tuned WADL, really nice and no work at all,
>>>>>>> maybe we
>>>>>>> could enhance the documentation there that it is working
>>>>>>> immediately for
>>>>>>> schema references as well without any additional configuration
>>>>>>> work -
>>>>>>> see http://cxf.apache.org/docs/jaxrs-services-description.html,
>>>>>>> currently it is a bit misleading because I initially thought I
>>>>>>> have to
>>>>>>> set WadlGenerator.schemaLocations to use embedded schemas, but
>>>>>>> this is
>>>>>>> actually not the case if schema include is used instead of
>>>>>>> xs:import!).
>>>>>>>
>>>>>>> Of course I can also add a switch to turn this off if someone really
>>>>>>> doesn't like it, but I think this will be rarely the case.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Johannes
>>>>>>>
>>>>>>>
>>>>>>> Am 18.08.2016 um 13:19 schrieb Sergey Beryozkin:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> thanks for the explanation.
>>>>>>>>
>>>>>>>> On 18/08/16 11:57, J. Fiala wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> If I'm using BeanValidation-annotations in my model classes,
>>>>>>>>> they are
>>>>>>>>> not picked up by the WADLGenerator and so are lost if I do code
>>>>>>>>> first
>>>>>>>>> and I have to look them up and model them in the WADL manually.
>>>>>>>>>
>>>>>>>>> At least @NotNull support would be nice, because this is really
>>>>>>>>> easy to
>>>>>>>>> do (see the PR).
>>>>>>>>>
>>>>>>>> WADLGenerator will set a required flag if it is 'int'/'boolean' as
>>>>>>>> opposed to Boolean/Integer
>>>>>>>>
>>>>>>>>> The others are a bit more tricky as they have to be generated as
>>>>>>>>> inline
>>>>>>>>> simpletypes and probably in the WADL would be replaced by existing
>>>>>>>>> simpletypes in the WADL/schema, but at least the developer has the
>>>>>>>>> hint
>>>>>>>>> there is a pattern/restriction in place.
>>>>>>>>> I already implemented @Size/@Min/@Max/@Pattern so you just have to
>>>>>>>>> pull
>>>>>>>>> it in.
>>>>>>>> I'd rather prefer to avoid going into all these schema
>>>>>>>> manipulations.
>>>>>>>> These hints can me made available in WADL grammar directly - have
>>>>>>>> you
>>>>>>>> checked if JAXB annotations can be used to set some of those
>>>>>>>> restrictions ? Another option: WADL generator can be configured
>>>>>>>> with a
>>>>>>>> prepared XML schema as opposed to generating it.
>>>>>>>>>
>>>>>>>>> So better support for the BeanValidation annotations makes code
>>>>>>>>> first a
>>>>>>>>> lot easier and also extending an existing WADL using code first
>>>>>>>>> for
>>>>>>>>> new
>>>>>>>>> model classes...
>>>>>>>> thanks, Sergey
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> Johannes
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 18.08.2016 um 00:29 schrieb Sergey Beryozkin:
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> Can you explain please what exactly the purpose of it can be ?
>>>>>>>>>> WADL generator simply reports the model info by using a JAXB
>>>>>>>>>> compiler
>>>>>>>>>> to generate XML schema, I'm trying to figure out how does the
>>>>>>>>>> bean
>>>>>>>>>> validation can help here or what it can change
>>>>>>>>>>
>>>>>>>>>> Sergey
>>>>>>>>>> On 17/08/16 18:18, J. Fiala wrote:
>>>>>>>>>>> I added this PR for bean-validation-support for query
>>>>>>>>>>> parameters:
>>>>>>>>>>> https://github.com/apache/cxf/pull/146
>>>>>>>>>>>
>>>>>>>>>>> This also adds the required-flag for params by supporting
>>>>>>>>>>> @NotNull
>>>>>>>>>>> (see
>>>>>>>>>>> related question here:
>>>>>>>>>>> http://stackoverflow.com/questions/13968261/required-queryparam-in-jax-rs-and-what-to-do-in-their-absence).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Additionally the PR adds support for @Size, @Min/@Max and
>>>>>>>>>>> @Pattern to
>>>>>>>>>>> the query parameters and will add the proper restrictions
>>>>>>>>>>> inline:
>>>>>>>>>>>
>>>>>>>>>>> * @NotNull - minOccurs="1"
>>>>>>>>>>>
>>>>>>>>>>> * @Size - "<xs:minLengthvalue = " + size.min() + "/>",
>>>>>>>>>>> "<xs:maxLengthvalue = " + size.max() + "/>"
>>>>>>>>>>>
>>>>>>>>>>> * @Min - "<xs:minInclusive value = " + min.value() + "/>"
>>>>>>>>>>>
>>>>>>>>>>> * @Min - "<xs:maxInclusive value = " + max.value() + "/>"
>>>>>>>>>>>
>>>>>>>>>>> * @Pattern - <xs:pattern value=" + pattern.regexp() + " />"
>>>>>>>>>>>
>>>>>>>>>>> For adding bean-validation-support to the complex types the JAXB
>>>>>>>>>>> processing / schema has to be parsed/filtered.
>>>>>>>>>>>
>>>>>>>>>>> The Java to schema mappings seems to be done here in
>>>>>>>>>>> WadlGenerator.java,
>>>>>>>>>>> line 1541:
>>>>>>>>>>> for (DOMResult r : JAXBUtils.generateJaxbSchemas(context,
>>>>>>>>>>> CastUtils.cast(Collections.emptyMap(),
>>>>>>>>>>> String.class,
>>>>>>>>>>> DOMResult.class))) {
>>>>>>>>>>>
>>>>>>>>>>> Am I correct in assuming we need a JAXB adapter which picks up
>>>>>>>>>>> the
>>>>>>>>>>> beanvalidation-annotations?
>>>>>>>>>>> https://docs.oracle.com/cd/E19316-01/819-3669/bnbdf/index.html
>>>>>>>>>>>
>>>>>>>>>>> So it seems we need to prepare the proper XmlAdapters
>>>>>>>>>>> (https://docs.oracle.com/javase/7/docs/api/javax/xml/bind/annotation/adapters/XmlAdapter.html)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> to generate the necessary restrictions in the schema.
>>>>>>>>>>>
>>>>>>>>>>> However, it would also be nice to also add proper SimpleTypes
>>>>>>>>>>> and
>>>>>>>>>>> reference them from the complexTypes (e.g. simpleType string_50
>>>>>>>>>>> for a
>>>>>>>>>>> string with a maximum of 50).
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>
>>>>>>>>>>> Johannes
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: WadlGenerator - Bean validation support for complex types?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Swagger JAX-RS is capable of generating Swagger JSON based on JAX-RS
annotations alone. Having partial schema fragment inside WADL param is
not good IMHO.
If you'd like to explore it further - do assume that parameters will
refer to XML Schema in WADL:grammar. WADL has XMLSchema loaded - so you
can use that data to analyze the types and add BeanVal annotations if
-beanValidation is enabled, using full class names of these annotations
without introducing a strong beanVal API dep
Many thanks, Sergey
On 11/09/16 10:00, J. Fiala wrote:
> Sergey,
>
> I think we can use the simpletype restrictions as already implemented in
> WadlGenerator and even use them in the SourceGenerator (wadl2java).
>
> I implemented a draft for Size(min,max) and Pattern, can you take a look
> in the PR (see SourceGenerator.java)?
>
> https://github.com/apache/cxf/pull/146
>
> If you like it, I'll add the other annotations.
> This allows usage of standard schema simpletypes and still get the
> beanvalidation annotations (without the need to use cxf:beanVal).
>
> The only thing missing is usage of the types in a separate schema, but
> that can be added later when access to the simpletypes is possible
> during the parameter processing.
>
> Best regards,
> Johannes
>
>
>
> Am 10.09.2016 um 21:41 schrieb J. Fiala:
>> Sergey,
>>
>> 1.) So we would have to map the complex types to the parameter list here.
>> I don't think this is a really good idea, I think the parameters
>> should always map to simpletypes.
>>
>> 2.) I think the cxf:beanVal extension is a good starting point for now
>> (as long as we don't get access to the types/restrictions backing the
>> parameters in the schema).
>> I think it would be readable and later can be easily ported to a type.
>> The only sad thing is that one has to define it for each parameter,
>> but we could also allow to define types maybe?.
>>
>> a) The easiest solution (add all restrictions to the parameter directly):
>> <!-- required can be easily picked from @NotNull --->
>> <wadl:param name="..." required="true" type="xs:string">
>> <cxf:beanValRestriction pattern="..." minLength="...."
>> maxLength="..." />
>> </wadl:param>
>>
>> <wadl:param name="..." required="true" type="xs:integer">
>> <cxf:beanValRestriction pattern="..." minInclusive="...."
>> maxInclusive="..." />
>> </wadl:param>\u2026
>>
>> b) Also allow usage of types (I believe much better):
>>
>> <wadl:param name="..." required="true"
>> type="xs:integer"><cxf:beanValRestriction type="mytype" /></wadl:param>\u2026
>> <cxf:type name="mytype" pattern="..." minLength=".." maxLength="..." />
>>
>> This way it would be possible to use search/replace once in the future
>> we are able to access the restrictions of the parameters!
>>
>> Regarding WadlGenerator: Here we could reuse this perfectly, simply
>> generate the appropriate cxf:beanValidationRestrictions (see 1.) the
>> easy way).
>>
>> So we have both code first/contract first covered with a solution
>> which is easy to use and also supports existing codebases with
>> BeanValidation-annotations.
>>
>> What do you think?
>>
>> Best regards,
>> Johannes
>>
>>
>> Am 08.09.2016 um 11:42 schrieb Sergey Beryozkin:
>>> Hi Johannes
>>>
>>> I suppose an idea which you have tried to do with enriching wadl:doc
>>> is useful - lets keep it in mind.
>>>
>>> So these ideas are proposed:
>>>
>>> 1. in WADL-first one simply has the query/header/path parameters
>>> referring to WADL grammar complex types - this will produce Java types
>>> with BeanVal annotations - and will require JAX-RS ParamConverters
>>> to to create these beans from Strings.
>>> Can you experiment with this option ? Bean val can then be done
>>> inside this param converter or with JAXRS BeanVal filer (or may be
>>> invoker).
>>>
>>> Nothing extra will need to be done on a source generator side for
>>> this to work.
>>>
>>> If this option works for WADL-first - then you can start thinking of
>>> how to make it work in the WADL-gen case - WADLGen may simply need to
>>> be enhanced to optionally add non-body JAX-RS parameter types to a
>>> JAXB context passed to JAXB schema compiler.
>>>
>>> 2. Introduce a cxf:beanVal extension which may be added to wadl:doc ?
>>>
>>> Sergey
>>>
>>>
>>>
>>> On 08/09/16 10:22, J. Fiala wrote:
>>>> Hi Sergey,
>>>>
>>>> No problem, the solution you suggested is of course the better way
>>>> regarding interoperability!
>>>>
>>>> (and great if it will work both ways eventually...!!)
>>>>
>>>> Best regards,
>>>>
>>>> Johannes
>>>>
>>>>
>>>> Am 08.09.2016 um 11:11 schrieb Sergey Beryozkin:
>>>>> Hi Johannes
>>>>>
>>>>> I'm sorry but I'm not seeing how this can be applied - you generate
>>>>> some schema types inside wadl:doc - it will never have a chance of any
>>>>> interoperability (non CXF wadl-to-java processing it) and looks like a
>>>>> 'perfect' hack :-) - I do appreciate your effort, thanks for that, but
>>>>> I'm not going to apply it.
>>>>>
>>>>> In the other thread we are discussing how starting from a WADL can
>>>>> somehow get Query (and indeed header/path) being BeanVal validated.
>>>>> The solution needs to work both ways. I.e - if we settle on the idea
>>>>> that a wadl:param refers to a complex grammar type then at least I can
>>>>> imagine that in a Java to WADL case somehow a Java class with Bean
>>>>> validations can be projected back into the grammar
>>>>>
>>>>> Cheers, Sergey
>>>>>
>>>>> On 08/09/16 08:41, J. Fiala wrote:
>>>>>> Hi Sergey,
>>>>>>
>>>>>> The point of the extension I did for the WadlGenerator (to add
>>>>>> simpletype restrictions to query parameters based on their
>>>>>> beanvalidation annotations - seee
>>>>>> https://github.com/apache/cxf/pull/146/files, WadlGenerator.java)
>>>>>> is to
>>>>>> support developers who have an existing codebase with lots of
>>>>>> BeanValidation annotations already annotated in the method
>>>>>> parameters.
>>>>>>
>>>>>> If they want to move these into a WADL contract it is really easy to
>>>>>> expose them first using the WadlGenerator and then pick the
>>>>>> simpletype
>>>>>> restrictions and move them out to schema. If you don't have these
>>>>>> in the
>>>>>> generated WADL, you have to do this from the code which is much more
>>>>>> work, doing this in the WADL only is much more fun.
>>>>>>
>>>>>> After this is done and the WADL is fine, of course they can
>>>>>> switch to
>>>>>> use the contract WADL and expose this instead of the generated WADL
>>>>>> (this feature works great including all schema references, I've
>>>>>> used it
>>>>>> with such a fine-tuned WADL, really nice and no work at all, maybe we
>>>>>> could enhance the documentation there that it is working
>>>>>> immediately for
>>>>>> schema references as well without any additional configuration work -
>>>>>> see http://cxf.apache.org/docs/jaxrs-services-description.html,
>>>>>> currently it is a bit misleading because I initially thought I
>>>>>> have to
>>>>>> set WadlGenerator.schemaLocations to use embedded schemas, but
>>>>>> this is
>>>>>> actually not the case if schema include is used instead of
>>>>>> xs:import!).
>>>>>>
>>>>>> Of course I can also add a switch to turn this off if someone really
>>>>>> doesn't like it, but I think this will be rarely the case.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Johannes
>>>>>>
>>>>>>
>>>>>> Am 18.08.2016 um 13:19 schrieb Sergey Beryozkin:
>>>>>>> Hi
>>>>>>>
>>>>>>> thanks for the explanation.
>>>>>>>
>>>>>>> On 18/08/16 11:57, J. Fiala wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> If I'm using BeanValidation-annotations in my model classes,
>>>>>>>> they are
>>>>>>>> not picked up by the WADLGenerator and so are lost if I do code
>>>>>>>> first
>>>>>>>> and I have to look them up and model them in the WADL manually.
>>>>>>>>
>>>>>>>> At least @NotNull support would be nice, because this is really
>>>>>>>> easy to
>>>>>>>> do (see the PR).
>>>>>>>>
>>>>>>> WADLGenerator will set a required flag if it is 'int'/'boolean' as
>>>>>>> opposed to Boolean/Integer
>>>>>>>
>>>>>>>> The others are a bit more tricky as they have to be generated as
>>>>>>>> inline
>>>>>>>> simpletypes and probably in the WADL would be replaced by existing
>>>>>>>> simpletypes in the WADL/schema, but at least the developer has the
>>>>>>>> hint
>>>>>>>> there is a pattern/restriction in place.
>>>>>>>> I already implemented @Size/@Min/@Max/@Pattern so you just have to
>>>>>>>> pull
>>>>>>>> it in.
>>>>>>> I'd rather prefer to avoid going into all these schema
>>>>>>> manipulations.
>>>>>>> These hints can me made available in WADL grammar directly - have
>>>>>>> you
>>>>>>> checked if JAXB annotations can be used to set some of those
>>>>>>> restrictions ? Another option: WADL generator can be configured
>>>>>>> with a
>>>>>>> prepared XML schema as opposed to generating it.
>>>>>>>>
>>>>>>>> So better support for the BeanValidation annotations makes code
>>>>>>>> first a
>>>>>>>> lot easier and also extending an existing WADL using code first for
>>>>>>>> new
>>>>>>>> model classes...
>>>>>>> thanks, Sergey
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Johannes
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 18.08.2016 um 00:29 schrieb Sergey Beryozkin:
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> Can you explain please what exactly the purpose of it can be ?
>>>>>>>>> WADL generator simply reports the model info by using a JAXB
>>>>>>>>> compiler
>>>>>>>>> to generate XML schema, I'm trying to figure out how does the bean
>>>>>>>>> validation can help here or what it can change
>>>>>>>>>
>>>>>>>>> Sergey
>>>>>>>>> On 17/08/16 18:18, J. Fiala wrote:
>>>>>>>>>> I added this PR for bean-validation-support for query parameters:
>>>>>>>>>> https://github.com/apache/cxf/pull/146
>>>>>>>>>>
>>>>>>>>>> This also adds the required-flag for params by supporting
>>>>>>>>>> @NotNull
>>>>>>>>>> (see
>>>>>>>>>> related question here:
>>>>>>>>>> http://stackoverflow.com/questions/13968261/required-queryparam-in-jax-rs-and-what-to-do-in-their-absence).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Additionally the PR adds support for @Size, @Min/@Max and
>>>>>>>>>> @Pattern to
>>>>>>>>>> the query parameters and will add the proper restrictions inline:
>>>>>>>>>>
>>>>>>>>>> * @NotNull - minOccurs="1"
>>>>>>>>>>
>>>>>>>>>> * @Size - "<xs:minLengthvalue = " + size.min() + "/>",
>>>>>>>>>> "<xs:maxLengthvalue = " + size.max() + "/>"
>>>>>>>>>>
>>>>>>>>>> * @Min - "<xs:minInclusive value = " + min.value() + "/>"
>>>>>>>>>>
>>>>>>>>>> * @Min - "<xs:maxInclusive value = " + max.value() + "/>"
>>>>>>>>>>
>>>>>>>>>> * @Pattern - <xs:pattern value=" + pattern.regexp() + " />"
>>>>>>>>>>
>>>>>>>>>> For adding bean-validation-support to the complex types the JAXB
>>>>>>>>>> processing / schema has to be parsed/filtered.
>>>>>>>>>>
>>>>>>>>>> The Java to schema mappings seems to be done here in
>>>>>>>>>> WadlGenerator.java,
>>>>>>>>>> line 1541:
>>>>>>>>>> for (DOMResult r : JAXBUtils.generateJaxbSchemas(context,
>>>>>>>>>> CastUtils.cast(Collections.emptyMap(),
>>>>>>>>>> String.class,
>>>>>>>>>> DOMResult.class))) {
>>>>>>>>>>
>>>>>>>>>> Am I correct in assuming we need a JAXB adapter which picks up
>>>>>>>>>> the
>>>>>>>>>> beanvalidation-annotations?
>>>>>>>>>> https://docs.oracle.com/cd/E19316-01/819-3669/bnbdf/index.html
>>>>>>>>>>
>>>>>>>>>> So it seems we need to prepare the proper XmlAdapters
>>>>>>>>>> (https://docs.oracle.com/javase/7/docs/api/javax/xml/bind/annotation/adapters/XmlAdapter.html)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> to generate the necessary restrictions in the schema.
>>>>>>>>>>
>>>>>>>>>> However, it would also be nice to also add proper SimpleTypes and
>>>>>>>>>> reference them from the complexTypes (e.g. simpleType string_50
>>>>>>>>>> for a
>>>>>>>>>> string with a maximum of 50).
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>
>>>>>>>>>> Johannes
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: WadlGenerator - Bean validation support for complex types?
Posted by "J. Fiala" <mo...@fwd.at>.
Sergey,
I think we can use the simpletype restrictions as already implemented in
WadlGenerator and even use them in the SourceGenerator (wadl2java).
I implemented a draft for Size(min,max) and Pattern, can you take a look
in the PR (see SourceGenerator.java)?
https://github.com/apache/cxf/pull/146
If you like it, I'll add the other annotations.
This allows usage of standard schema simpletypes and still get the
beanvalidation annotations (without the need to use cxf:beanVal).
The only thing missing is usage of the types in a separate schema, but
that can be added later when access to the simpletypes is possible
during the parameter processing.
Best regards,
Johannes
Am 10.09.2016 um 21:41 schrieb J. Fiala:
> Sergey,
>
> 1.) So we would have to map the complex types to the parameter list here.
> I don't think this is a really good idea, I think the parameters
> should always map to simpletypes.
>
> 2.) I think the cxf:beanVal extension is a good starting point for now
> (as long as we don't get access to the types/restrictions backing the
> parameters in the schema).
> I think it would be readable and later can be easily ported to a type.
> The only sad thing is that one has to define it for each parameter,
> but we could also allow to define types maybe?.
>
> a) The easiest solution (add all restrictions to the parameter directly):
> <!-- required can be easily picked from @NotNull --->
> <wadl:param name="..." required="true" type="xs:string">
> <cxf:beanValRestriction pattern="..." minLength="...."
> maxLength="..." />
> </wadl:param>
>
> <wadl:param name="..." required="true" type="xs:integer">
> <cxf:beanValRestriction pattern="..." minInclusive="...."
> maxInclusive="..." />
> </wadl:param>\u2026
>
> b) Also allow usage of types (I believe much better):
>
> <wadl:param name="..." required="true"
> type="xs:integer"><cxf:beanValRestriction type="mytype" /></wadl:param>\u2026
> <cxf:type name="mytype" pattern="..." minLength=".." maxLength="..." />
>
> This way it would be possible to use search/replace once in the future
> we are able to access the restrictions of the parameters!
>
> Regarding WadlGenerator: Here we could reuse this perfectly, simply
> generate the appropriate cxf:beanValidationRestrictions (see 1.) the
> easy way).
>
> So we have both code first/contract first covered with a solution
> which is easy to use and also supports existing codebases with
> BeanValidation-annotations.
>
> What do you think?
>
> Best regards,
> Johannes
>
>
> Am 08.09.2016 um 11:42 schrieb Sergey Beryozkin:
>> Hi Johannes
>>
>> I suppose an idea which you have tried to do with enriching wadl:doc
>> is useful - lets keep it in mind.
>>
>> So these ideas are proposed:
>>
>> 1. in WADL-first one simply has the query/header/path parameters
>> referring to WADL grammar complex types - this will produce Java types
>> with BeanVal annotations - and will require JAX-RS ParamConverters
>> to to create these beans from Strings.
>> Can you experiment with this option ? Bean val can then be done
>> inside this param converter or with JAXRS BeanVal filer (or may be
>> invoker).
>>
>> Nothing extra will need to be done on a source generator side for
>> this to work.
>>
>> If this option works for WADL-first - then you can start thinking of
>> how to make it work in the WADL-gen case - WADLGen may simply need to
>> be enhanced to optionally add non-body JAX-RS parameter types to a
>> JAXB context passed to JAXB schema compiler.
>>
>> 2. Introduce a cxf:beanVal extension which may be added to wadl:doc ?
>>
>> Sergey
>>
>>
>>
>> On 08/09/16 10:22, J. Fiala wrote:
>>> Hi Sergey,
>>>
>>> No problem, the solution you suggested is of course the better way
>>> regarding interoperability!
>>>
>>> (and great if it will work both ways eventually...!!)
>>>
>>> Best regards,
>>>
>>> Johannes
>>>
>>>
>>> Am 08.09.2016 um 11:11 schrieb Sergey Beryozkin:
>>>> Hi Johannes
>>>>
>>>> I'm sorry but I'm not seeing how this can be applied - you generate
>>>> some schema types inside wadl:doc - it will never have a chance of any
>>>> interoperability (non CXF wadl-to-java processing it) and looks like a
>>>> 'perfect' hack :-) - I do appreciate your effort, thanks for that, but
>>>> I'm not going to apply it.
>>>>
>>>> In the other thread we are discussing how starting from a WADL can
>>>> somehow get Query (and indeed header/path) being BeanVal validated.
>>>> The solution needs to work both ways. I.e - if we settle on the idea
>>>> that a wadl:param refers to a complex grammar type then at least I can
>>>> imagine that in a Java to WADL case somehow a Java class with Bean
>>>> validations can be projected back into the grammar
>>>>
>>>> Cheers, Sergey
>>>>
>>>> On 08/09/16 08:41, J. Fiala wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> The point of the extension I did for the WadlGenerator (to add
>>>>> simpletype restrictions to query parameters based on their
>>>>> beanvalidation annotations - seee
>>>>> https://github.com/apache/cxf/pull/146/files, WadlGenerator.java)
>>>>> is to
>>>>> support developers who have an existing codebase with lots of
>>>>> BeanValidation annotations already annotated in the method
>>>>> parameters.
>>>>>
>>>>> If they want to move these into a WADL contract it is really easy to
>>>>> expose them first using the WadlGenerator and then pick the
>>>>> simpletype
>>>>> restrictions and move them out to schema. If you don't have these
>>>>> in the
>>>>> generated WADL, you have to do this from the code which is much more
>>>>> work, doing this in the WADL only is much more fun.
>>>>>
>>>>> After this is done and the WADL is fine, of course they can
>>>>> switch to
>>>>> use the contract WADL and expose this instead of the generated WADL
>>>>> (this feature works great including all schema references, I've
>>>>> used it
>>>>> with such a fine-tuned WADL, really nice and no work at all, maybe we
>>>>> could enhance the documentation there that it is working
>>>>> immediately for
>>>>> schema references as well without any additional configuration work -
>>>>> see http://cxf.apache.org/docs/jaxrs-services-description.html,
>>>>> currently it is a bit misleading because I initially thought I
>>>>> have to
>>>>> set WadlGenerator.schemaLocations to use embedded schemas, but
>>>>> this is
>>>>> actually not the case if schema include is used instead of
>>>>> xs:import!).
>>>>>
>>>>> Of course I can also add a switch to turn this off if someone really
>>>>> doesn't like it, but I think this will be rarely the case.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Johannes
>>>>>
>>>>>
>>>>> Am 18.08.2016 um 13:19 schrieb Sergey Beryozkin:
>>>>>> Hi
>>>>>>
>>>>>> thanks for the explanation.
>>>>>>
>>>>>> On 18/08/16 11:57, J. Fiala wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> If I'm using BeanValidation-annotations in my model classes,
>>>>>>> they are
>>>>>>> not picked up by the WADLGenerator and so are lost if I do code
>>>>>>> first
>>>>>>> and I have to look them up and model them in the WADL manually.
>>>>>>>
>>>>>>> At least @NotNull support would be nice, because this is really
>>>>>>> easy to
>>>>>>> do (see the PR).
>>>>>>>
>>>>>> WADLGenerator will set a required flag if it is 'int'/'boolean' as
>>>>>> opposed to Boolean/Integer
>>>>>>
>>>>>>> The others are a bit more tricky as they have to be generated as
>>>>>>> inline
>>>>>>> simpletypes and probably in the WADL would be replaced by existing
>>>>>>> simpletypes in the WADL/schema, but at least the developer has the
>>>>>>> hint
>>>>>>> there is a pattern/restriction in place.
>>>>>>> I already implemented @Size/@Min/@Max/@Pattern so you just have to
>>>>>>> pull
>>>>>>> it in.
>>>>>> I'd rather prefer to avoid going into all these schema
>>>>>> manipulations.
>>>>>> These hints can me made available in WADL grammar directly - have
>>>>>> you
>>>>>> checked if JAXB annotations can be used to set some of those
>>>>>> restrictions ? Another option: WADL generator can be configured
>>>>>> with a
>>>>>> prepared XML schema as opposed to generating it.
>>>>>>>
>>>>>>> So better support for the BeanValidation annotations makes code
>>>>>>> first a
>>>>>>> lot easier and also extending an existing WADL using code first for
>>>>>>> new
>>>>>>> model classes...
>>>>>> thanks, Sergey
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Johannes
>>>>>>>
>>>>>>>
>>>>>>> Am 18.08.2016 um 00:29 schrieb Sergey Beryozkin:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> Can you explain please what exactly the purpose of it can be ?
>>>>>>>> WADL generator simply reports the model info by using a JAXB
>>>>>>>> compiler
>>>>>>>> to generate XML schema, I'm trying to figure out how does the bean
>>>>>>>> validation can help here or what it can change
>>>>>>>>
>>>>>>>> Sergey
>>>>>>>> On 17/08/16 18:18, J. Fiala wrote:
>>>>>>>>> I added this PR for bean-validation-support for query parameters:
>>>>>>>>> https://github.com/apache/cxf/pull/146
>>>>>>>>>
>>>>>>>>> This also adds the required-flag for params by supporting
>>>>>>>>> @NotNull
>>>>>>>>> (see
>>>>>>>>> related question here:
>>>>>>>>> http://stackoverflow.com/questions/13968261/required-queryparam-in-jax-rs-and-what-to-do-in-their-absence).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Additionally the PR adds support for @Size, @Min/@Max and
>>>>>>>>> @Pattern to
>>>>>>>>> the query parameters and will add the proper restrictions inline:
>>>>>>>>>
>>>>>>>>> * @NotNull - minOccurs="1"
>>>>>>>>>
>>>>>>>>> * @Size - "<xs:minLengthvalue = " + size.min() + "/>",
>>>>>>>>> "<xs:maxLengthvalue = " + size.max() + "/>"
>>>>>>>>>
>>>>>>>>> * @Min - "<xs:minInclusive value = " + min.value() + "/>"
>>>>>>>>>
>>>>>>>>> * @Min - "<xs:maxInclusive value = " + max.value() + "/>"
>>>>>>>>>
>>>>>>>>> * @Pattern - <xs:pattern value=" + pattern.regexp() + " />"
>>>>>>>>>
>>>>>>>>> For adding bean-validation-support to the complex types the JAXB
>>>>>>>>> processing / schema has to be parsed/filtered.
>>>>>>>>>
>>>>>>>>> The Java to schema mappings seems to be done here in
>>>>>>>>> WadlGenerator.java,
>>>>>>>>> line 1541:
>>>>>>>>> for (DOMResult r : JAXBUtils.generateJaxbSchemas(context,
>>>>>>>>> CastUtils.cast(Collections.emptyMap(),
>>>>>>>>> String.class,
>>>>>>>>> DOMResult.class))) {
>>>>>>>>>
>>>>>>>>> Am I correct in assuming we need a JAXB adapter which picks up
>>>>>>>>> the
>>>>>>>>> beanvalidation-annotations?
>>>>>>>>> https://docs.oracle.com/cd/E19316-01/819-3669/bnbdf/index.html
>>>>>>>>>
>>>>>>>>> So it seems we need to prepare the proper XmlAdapters
>>>>>>>>> (https://docs.oracle.com/javase/7/docs/api/javax/xml/bind/annotation/adapters/XmlAdapter.html)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> to generate the necessary restrictions in the schema.
>>>>>>>>>
>>>>>>>>> However, it would also be nice to also add proper SimpleTypes and
>>>>>>>>> reference them from the complexTypes (e.g. simpleType string_50
>>>>>>>>> for a
>>>>>>>>> string with a maximum of 50).
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> Johannes
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>
Re: WadlGenerator - Bean validation support for complex types?
Posted by "J. Fiala" <mo...@fwd.at>.
Sergey,
1.) So we would have to map the complex types to the parameter list here.
I don't think this is a really good idea, I think the parameters should
always map to simpletypes.
2.) I think the cxf:beanVal extension is a good starting point for now
(as long as we don't get access to the types/restrictions backing the
parameters in the schema).
I think it would be readable and later can be easily ported to a type.
The only sad thing is that one has to define it for each parameter, but
we could also allow to define types maybe?.
a) The easiest solution (add all restrictions to the parameter directly):
<!-- required can be easily picked from @NotNull --->
<wadl:param name="..." required="true" type="xs:string">
<cxf:beanValRestriction pattern="..." minLength="...."
maxLength="..." />
</wadl:param>
<wadl:param name="..." required="true" type="xs:integer">
<cxf:beanValRestriction pattern="..." minInclusive="...."
maxInclusive="..." />
</wadl:param>\u2026
b) Also allow usage of types (I believe much better):
<wadl:param name="..." required="true"
type="xs:integer"><cxf:beanValRestriction type="mytype" /></wadl:param>\u2026
<cxf:type name="mytype" pattern="..." minLength=".." maxLength="..." />
This way it would be possible to use search/replace once in the future
we are able to access the restrictions of the parameters!
Regarding WadlGenerator: Here we could reuse this perfectly, simply
generate the appropriate cxf:beanValidationRestrictions (see 1.) the
easy way).
So we have both code first/contract first covered with a solution which
is easy to use and also supports existing codebases with
BeanValidation-annotations.
What do you think?
Best regards,
Johannes
Am 08.09.2016 um 11:42 schrieb Sergey Beryozkin:
> Hi Johannes
>
> I suppose an idea which you have tried to do with enriching wadl:doc
> is useful - lets keep it in mind.
>
> So these ideas are proposed:
>
> 1. in WADL-first one simply has the query/header/path parameters
> referring to WADL grammar complex types - this will produce Java types
> with BeanVal annotations - and will require JAX-RS ParamConverters to
> to create these beans from Strings.
> Can you experiment with this option ? Bean val can then be done inside
> this param converter or with JAXRS BeanVal filer (or may be invoker).
>
> Nothing extra will need to be done on a source generator side for this
> to work.
>
> If this option works for WADL-first - then you can start thinking of
> how to make it work in the WADL-gen case - WADLGen may simply need to
> be enhanced to optionally add non-body JAX-RS parameter types to a
> JAXB context passed to JAXB schema compiler.
>
> 2. Introduce a cxf:beanVal extension which may be added to wadl:doc ?
>
> Sergey
>
>
>
> On 08/09/16 10:22, J. Fiala wrote:
>> Hi Sergey,
>>
>> No problem, the solution you suggested is of course the better way
>> regarding interoperability!
>>
>> (and great if it will work both ways eventually...!!)
>>
>> Best regards,
>>
>> Johannes
>>
>>
>> Am 08.09.2016 um 11:11 schrieb Sergey Beryozkin:
>>> Hi Johannes
>>>
>>> I'm sorry but I'm not seeing how this can be applied - you generate
>>> some schema types inside wadl:doc - it will never have a chance of any
>>> interoperability (non CXF wadl-to-java processing it) and looks like a
>>> 'perfect' hack :-) - I do appreciate your effort, thanks for that, but
>>> I'm not going to apply it.
>>>
>>> In the other thread we are discussing how starting from a WADL can
>>> somehow get Query (and indeed header/path) being BeanVal validated.
>>> The solution needs to work both ways. I.e - if we settle on the idea
>>> that a wadl:param refers to a complex grammar type then at least I can
>>> imagine that in a Java to WADL case somehow a Java class with Bean
>>> validations can be projected back into the grammar
>>>
>>> Cheers, Sergey
>>>
>>> On 08/09/16 08:41, J. Fiala wrote:
>>>> Hi Sergey,
>>>>
>>>> The point of the extension I did for the WadlGenerator (to add
>>>> simpletype restrictions to query parameters based on their
>>>> beanvalidation annotations - seee
>>>> https://github.com/apache/cxf/pull/146/files, WadlGenerator.java)
>>>> is to
>>>> support developers who have an existing codebase with lots of
>>>> BeanValidation annotations already annotated in the method parameters.
>>>>
>>>> If they want to move these into a WADL contract it is really easy to
>>>> expose them first using the WadlGenerator and then pick the simpletype
>>>> restrictions and move them out to schema. If you don't have these
>>>> in the
>>>> generated WADL, you have to do this from the code which is much more
>>>> work, doing this in the WADL only is much more fun.
>>>>
>>>> After this is done and the WADL is fine, of course they can switch to
>>>> use the contract WADL and expose this instead of the generated WADL
>>>> (this feature works great including all schema references, I've
>>>> used it
>>>> with such a fine-tuned WADL, really nice and no work at all, maybe we
>>>> could enhance the documentation there that it is working
>>>> immediately for
>>>> schema references as well without any additional configuration work -
>>>> see http://cxf.apache.org/docs/jaxrs-services-description.html,
>>>> currently it is a bit misleading because I initially thought I have to
>>>> set WadlGenerator.schemaLocations to use embedded schemas, but this is
>>>> actually not the case if schema include is used instead of
>>>> xs:import!).
>>>>
>>>> Of course I can also add a switch to turn this off if someone really
>>>> doesn't like it, but I think this will be rarely the case.
>>>>
>>>> Best regards,
>>>>
>>>> Johannes
>>>>
>>>>
>>>> Am 18.08.2016 um 13:19 schrieb Sergey Beryozkin:
>>>>> Hi
>>>>>
>>>>> thanks for the explanation.
>>>>>
>>>>> On 18/08/16 11:57, J. Fiala wrote:
>>>>>> Hi,
>>>>>>
>>>>>> If I'm using BeanValidation-annotations in my model classes, they
>>>>>> are
>>>>>> not picked up by the WADLGenerator and so are lost if I do code
>>>>>> first
>>>>>> and I have to look them up and model them in the WADL manually.
>>>>>>
>>>>>> At least @NotNull support would be nice, because this is really
>>>>>> easy to
>>>>>> do (see the PR).
>>>>>>
>>>>> WADLGenerator will set a required flag if it is 'int'/'boolean' as
>>>>> opposed to Boolean/Integer
>>>>>
>>>>>> The others are a bit more tricky as they have to be generated as
>>>>>> inline
>>>>>> simpletypes and probably in the WADL would be replaced by existing
>>>>>> simpletypes in the WADL/schema, but at least the developer has the
>>>>>> hint
>>>>>> there is a pattern/restriction in place.
>>>>>> I already implemented @Size/@Min/@Max/@Pattern so you just have to
>>>>>> pull
>>>>>> it in.
>>>>> I'd rather prefer to avoid going into all these schema manipulations.
>>>>> These hints can me made available in WADL grammar directly - have you
>>>>> checked if JAXB annotations can be used to set some of those
>>>>> restrictions ? Another option: WADL generator can be configured
>>>>> with a
>>>>> prepared XML schema as opposed to generating it.
>>>>>>
>>>>>> So better support for the BeanValidation annotations makes code
>>>>>> first a
>>>>>> lot easier and also extending an existing WADL using code first for
>>>>>> new
>>>>>> model classes...
>>>>> thanks, Sergey
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Johannes
>>>>>>
>>>>>>
>>>>>> Am 18.08.2016 um 00:29 schrieb Sergey Beryozkin:
>>>>>>> Hi
>>>>>>>
>>>>>>> Can you explain please what exactly the purpose of it can be ?
>>>>>>> WADL generator simply reports the model info by using a JAXB
>>>>>>> compiler
>>>>>>> to generate XML schema, I'm trying to figure out how does the bean
>>>>>>> validation can help here or what it can change
>>>>>>>
>>>>>>> Sergey
>>>>>>> On 17/08/16 18:18, J. Fiala wrote:
>>>>>>>> I added this PR for bean-validation-support for query parameters:
>>>>>>>> https://github.com/apache/cxf/pull/146
>>>>>>>>
>>>>>>>> This also adds the required-flag for params by supporting @NotNull
>>>>>>>> (see
>>>>>>>> related question here:
>>>>>>>> http://stackoverflow.com/questions/13968261/required-queryparam-in-jax-rs-and-what-to-do-in-their-absence).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Additionally the PR adds support for @Size, @Min/@Max and
>>>>>>>> @Pattern to
>>>>>>>> the query parameters and will add the proper restrictions inline:
>>>>>>>>
>>>>>>>> * @NotNull - minOccurs="1"
>>>>>>>>
>>>>>>>> * @Size - "<xs:minLengthvalue = " + size.min() + "/>",
>>>>>>>> "<xs:maxLengthvalue = " + size.max() + "/>"
>>>>>>>>
>>>>>>>> * @Min - "<xs:minInclusive value = " + min.value() + "/>"
>>>>>>>>
>>>>>>>> * @Min - "<xs:maxInclusive value = " + max.value() + "/>"
>>>>>>>>
>>>>>>>> * @Pattern - <xs:pattern value=" + pattern.regexp() + " />"
>>>>>>>>
>>>>>>>> For adding bean-validation-support to the complex types the JAXB
>>>>>>>> processing / schema has to be parsed/filtered.
>>>>>>>>
>>>>>>>> The Java to schema mappings seems to be done here in
>>>>>>>> WadlGenerator.java,
>>>>>>>> line 1541:
>>>>>>>> for (DOMResult r : JAXBUtils.generateJaxbSchemas(context,
>>>>>>>> CastUtils.cast(Collections.emptyMap(),
>>>>>>>> String.class,
>>>>>>>> DOMResult.class))) {
>>>>>>>>
>>>>>>>> Am I correct in assuming we need a JAXB adapter which picks up the
>>>>>>>> beanvalidation-annotations?
>>>>>>>> https://docs.oracle.com/cd/E19316-01/819-3669/bnbdf/index.html
>>>>>>>>
>>>>>>>> So it seems we need to prepare the proper XmlAdapters
>>>>>>>> (https://docs.oracle.com/javase/7/docs/api/javax/xml/bind/annotation/adapters/XmlAdapter.html)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> to generate the necessary restrictions in the schema.
>>>>>>>>
>>>>>>>> However, it would also be nice to also add proper SimpleTypes and
>>>>>>>> reference them from the complexTypes (e.g. simpleType string_50
>>>>>>>> for a
>>>>>>>> string with a maximum of 50).
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Johannes
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: WadlGenerator - Bean validation support for complex types?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Johannes
I suppose an idea which you have tried to do with enriching wadl:doc is
useful - lets keep it in mind.
So these ideas are proposed:
1. in WADL-first one simply has the query/header/path parameters
referring to WADL grammar complex types - this will produce Java types
with BeanVal annotations - and will require JAX-RS ParamConverters to
to create these beans from Strings.
Can you experiment with this option ? Bean val can then be done inside
this param converter or with JAXRS BeanVal filer (or may be invoker).
Nothing extra will need to be done on a source generator side for this
to work.
If this option works for WADL-first - then you can start thinking of how
to make it work in the WADL-gen case - WADLGen may simply need to be
enhanced to optionally add non-body JAX-RS parameter types to a JAXB
context passed to JAXB schema compiler.
2. Introduce a cxf:beanVal extension which may be added to wadl:doc ?
Sergey
On 08/09/16 10:22, J. Fiala wrote:
> Hi Sergey,
>
> No problem, the solution you suggested is of course the better way
> regarding interoperability!
>
> (and great if it will work both ways eventually...!!)
>
> Best regards,
>
> Johannes
>
>
> Am 08.09.2016 um 11:11 schrieb Sergey Beryozkin:
>> Hi Johannes
>>
>> I'm sorry but I'm not seeing how this can be applied - you generate
>> some schema types inside wadl:doc - it will never have a chance of any
>> interoperability (non CXF wadl-to-java processing it) and looks like a
>> 'perfect' hack :-) - I do appreciate your effort, thanks for that, but
>> I'm not going to apply it.
>>
>> In the other thread we are discussing how starting from a WADL can
>> somehow get Query (and indeed header/path) being BeanVal validated.
>> The solution needs to work both ways. I.e - if we settle on the idea
>> that a wadl:param refers to a complex grammar type then at least I can
>> imagine that in a Java to WADL case somehow a Java class with Bean
>> validations can be projected back into the grammar
>>
>> Cheers, Sergey
>>
>> On 08/09/16 08:41, J. Fiala wrote:
>>> Hi Sergey,
>>>
>>> The point of the extension I did for the WadlGenerator (to add
>>> simpletype restrictions to query parameters based on their
>>> beanvalidation annotations - seee
>>> https://github.com/apache/cxf/pull/146/files, WadlGenerator.java) is to
>>> support developers who have an existing codebase with lots of
>>> BeanValidation annotations already annotated in the method parameters.
>>>
>>> If they want to move these into a WADL contract it is really easy to
>>> expose them first using the WadlGenerator and then pick the simpletype
>>> restrictions and move them out to schema. If you don't have these in the
>>> generated WADL, you have to do this from the code which is much more
>>> work, doing this in the WADL only is much more fun.
>>>
>>> After this is done and the WADL is fine, of course they can switch to
>>> use the contract WADL and expose this instead of the generated WADL
>>> (this feature works great including all schema references, I've used it
>>> with such a fine-tuned WADL, really nice and no work at all, maybe we
>>> could enhance the documentation there that it is working immediately for
>>> schema references as well without any additional configuration work -
>>> see http://cxf.apache.org/docs/jaxrs-services-description.html,
>>> currently it is a bit misleading because I initially thought I have to
>>> set WadlGenerator.schemaLocations to use embedded schemas, but this is
>>> actually not the case if schema include is used instead of xs:import!).
>>>
>>> Of course I can also add a switch to turn this off if someone really
>>> doesn't like it, but I think this will be rarely the case.
>>>
>>> Best regards,
>>>
>>> Johannes
>>>
>>>
>>> Am 18.08.2016 um 13:19 schrieb Sergey Beryozkin:
>>>> Hi
>>>>
>>>> thanks for the explanation.
>>>>
>>>> On 18/08/16 11:57, J. Fiala wrote:
>>>>> Hi,
>>>>>
>>>>> If I'm using BeanValidation-annotations in my model classes, they are
>>>>> not picked up by the WADLGenerator and so are lost if I do code first
>>>>> and I have to look them up and model them in the WADL manually.
>>>>>
>>>>> At least @NotNull support would be nice, because this is really
>>>>> easy to
>>>>> do (see the PR).
>>>>>
>>>> WADLGenerator will set a required flag if it is 'int'/'boolean' as
>>>> opposed to Boolean/Integer
>>>>
>>>>> The others are a bit more tricky as they have to be generated as
>>>>> inline
>>>>> simpletypes and probably in the WADL would be replaced by existing
>>>>> simpletypes in the WADL/schema, but at least the developer has the
>>>>> hint
>>>>> there is a pattern/restriction in place.
>>>>> I already implemented @Size/@Min/@Max/@Pattern so you just have to
>>>>> pull
>>>>> it in.
>>>> I'd rather prefer to avoid going into all these schema manipulations.
>>>> These hints can me made available in WADL grammar directly - have you
>>>> checked if JAXB annotations can be used to set some of those
>>>> restrictions ? Another option: WADL generator can be configured with a
>>>> prepared XML schema as opposed to generating it.
>>>>>
>>>>> So better support for the BeanValidation annotations makes code
>>>>> first a
>>>>> lot easier and also extending an existing WADL using code first for
>>>>> new
>>>>> model classes...
>>>> thanks, Sergey
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Johannes
>>>>>
>>>>>
>>>>> Am 18.08.2016 um 00:29 schrieb Sergey Beryozkin:
>>>>>> Hi
>>>>>>
>>>>>> Can you explain please what exactly the purpose of it can be ?
>>>>>> WADL generator simply reports the model info by using a JAXB compiler
>>>>>> to generate XML schema, I'm trying to figure out how does the bean
>>>>>> validation can help here or what it can change
>>>>>>
>>>>>> Sergey
>>>>>> On 17/08/16 18:18, J. Fiala wrote:
>>>>>>> I added this PR for bean-validation-support for query parameters:
>>>>>>> https://github.com/apache/cxf/pull/146
>>>>>>>
>>>>>>> This also adds the required-flag for params by supporting @NotNull
>>>>>>> (see
>>>>>>> related question here:
>>>>>>> http://stackoverflow.com/questions/13968261/required-queryparam-in-jax-rs-and-what-to-do-in-their-absence).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Additionally the PR adds support for @Size, @Min/@Max and
>>>>>>> @Pattern to
>>>>>>> the query parameters and will add the proper restrictions inline:
>>>>>>>
>>>>>>> * @NotNull - minOccurs="1"
>>>>>>>
>>>>>>> * @Size - "<xs:minLengthvalue = " + size.min() + "/>",
>>>>>>> "<xs:maxLengthvalue = " + size.max() + "/>"
>>>>>>>
>>>>>>> * @Min - "<xs:minInclusive value = " + min.value() + "/>"
>>>>>>>
>>>>>>> * @Min - "<xs:maxInclusive value = " + max.value() + "/>"
>>>>>>>
>>>>>>> * @Pattern - <xs:pattern value=" + pattern.regexp() + " />"
>>>>>>>
>>>>>>> For adding bean-validation-support to the complex types the JAXB
>>>>>>> processing / schema has to be parsed/filtered.
>>>>>>>
>>>>>>> The Java to schema mappings seems to be done here in
>>>>>>> WadlGenerator.java,
>>>>>>> line 1541:
>>>>>>> for (DOMResult r : JAXBUtils.generateJaxbSchemas(context,
>>>>>>> CastUtils.cast(Collections.emptyMap(),
>>>>>>> String.class,
>>>>>>> DOMResult.class))) {
>>>>>>>
>>>>>>> Am I correct in assuming we need a JAXB adapter which picks up the
>>>>>>> beanvalidation-annotations?
>>>>>>> https://docs.oracle.com/cd/E19316-01/819-3669/bnbdf/index.html
>>>>>>>
>>>>>>> So it seems we need to prepare the proper XmlAdapters
>>>>>>> (https://docs.oracle.com/javase/7/docs/api/javax/xml/bind/annotation/adapters/XmlAdapter.html)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> to generate the necessary restrictions in the schema.
>>>>>>>
>>>>>>> However, it would also be nice to also add proper SimpleTypes and
>>>>>>> reference them from the complexTypes (e.g. simpleType string_50
>>>>>>> for a
>>>>>>> string with a maximum of 50).
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Johannes
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: WadlGenerator - Bean validation support for complex types?
Posted by "J. Fiala" <mo...@fwd.at>.
Hi Sergey,
No problem, the solution you suggested is of course the better way
regarding interoperability!
(and great if it will work both ways eventually...!!)
Best regards,
Johannes
Am 08.09.2016 um 11:11 schrieb Sergey Beryozkin:
> Hi Johannes
>
> I'm sorry but I'm not seeing how this can be applied - you generate
> some schema types inside wadl:doc - it will never have a chance of any
> interoperability (non CXF wadl-to-java processing it) and looks like a
> 'perfect' hack :-) - I do appreciate your effort, thanks for that, but
> I'm not going to apply it.
>
> In the other thread we are discussing how starting from a WADL can
> somehow get Query (and indeed header/path) being BeanVal validated.
> The solution needs to work both ways. I.e - if we settle on the idea
> that a wadl:param refers to a complex grammar type then at least I can
> imagine that in a Java to WADL case somehow a Java class with Bean
> validations can be projected back into the grammar
>
> Cheers, Sergey
>
> On 08/09/16 08:41, J. Fiala wrote:
>> Hi Sergey,
>>
>> The point of the extension I did for the WadlGenerator (to add
>> simpletype restrictions to query parameters based on their
>> beanvalidation annotations - seee
>> https://github.com/apache/cxf/pull/146/files, WadlGenerator.java) is to
>> support developers who have an existing codebase with lots of
>> BeanValidation annotations already annotated in the method parameters.
>>
>> If they want to move these into a WADL contract it is really easy to
>> expose them first using the WadlGenerator and then pick the simpletype
>> restrictions and move them out to schema. If you don't have these in the
>> generated WADL, you have to do this from the code which is much more
>> work, doing this in the WADL only is much more fun.
>>
>> After this is done and the WADL is fine, of course they can switch to
>> use the contract WADL and expose this instead of the generated WADL
>> (this feature works great including all schema references, I've used it
>> with such a fine-tuned WADL, really nice and no work at all, maybe we
>> could enhance the documentation there that it is working immediately for
>> schema references as well without any additional configuration work -
>> see http://cxf.apache.org/docs/jaxrs-services-description.html,
>> currently it is a bit misleading because I initially thought I have to
>> set WadlGenerator.schemaLocations to use embedded schemas, but this is
>> actually not the case if schema include is used instead of xs:import!).
>>
>> Of course I can also add a switch to turn this off if someone really
>> doesn't like it, but I think this will be rarely the case.
>>
>> Best regards,
>>
>> Johannes
>>
>>
>> Am 18.08.2016 um 13:19 schrieb Sergey Beryozkin:
>>> Hi
>>>
>>> thanks for the explanation.
>>>
>>> On 18/08/16 11:57, J. Fiala wrote:
>>>> Hi,
>>>>
>>>> If I'm using BeanValidation-annotations in my model classes, they are
>>>> not picked up by the WADLGenerator and so are lost if I do code first
>>>> and I have to look them up and model them in the WADL manually.
>>>>
>>>> At least @NotNull support would be nice, because this is really
>>>> easy to
>>>> do (see the PR).
>>>>
>>> WADLGenerator will set a required flag if it is 'int'/'boolean' as
>>> opposed to Boolean/Integer
>>>
>>>> The others are a bit more tricky as they have to be generated as
>>>> inline
>>>> simpletypes and probably in the WADL would be replaced by existing
>>>> simpletypes in the WADL/schema, but at least the developer has the
>>>> hint
>>>> there is a pattern/restriction in place.
>>>> I already implemented @Size/@Min/@Max/@Pattern so you just have to
>>>> pull
>>>> it in.
>>> I'd rather prefer to avoid going into all these schema manipulations.
>>> These hints can me made available in WADL grammar directly - have you
>>> checked if JAXB annotations can be used to set some of those
>>> restrictions ? Another option: WADL generator can be configured with a
>>> prepared XML schema as opposed to generating it.
>>>>
>>>> So better support for the BeanValidation annotations makes code
>>>> first a
>>>> lot easier and also extending an existing WADL using code first for
>>>> new
>>>> model classes...
>>> thanks, Sergey
>>>>
>>>> Best regards,
>>>>
>>>> Johannes
>>>>
>>>>
>>>> Am 18.08.2016 um 00:29 schrieb Sergey Beryozkin:
>>>>> Hi
>>>>>
>>>>> Can you explain please what exactly the purpose of it can be ?
>>>>> WADL generator simply reports the model info by using a JAXB compiler
>>>>> to generate XML schema, I'm trying to figure out how does the bean
>>>>> validation can help here or what it can change
>>>>>
>>>>> Sergey
>>>>> On 17/08/16 18:18, J. Fiala wrote:
>>>>>> I added this PR for bean-validation-support for query parameters:
>>>>>> https://github.com/apache/cxf/pull/146
>>>>>>
>>>>>> This also adds the required-flag for params by supporting @NotNull
>>>>>> (see
>>>>>> related question here:
>>>>>> http://stackoverflow.com/questions/13968261/required-queryparam-in-jax-rs-and-what-to-do-in-their-absence).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Additionally the PR adds support for @Size, @Min/@Max and
>>>>>> @Pattern to
>>>>>> the query parameters and will add the proper restrictions inline:
>>>>>>
>>>>>> * @NotNull - minOccurs="1"
>>>>>>
>>>>>> * @Size - "<xs:minLengthvalue = " + size.min() + "/>",
>>>>>> "<xs:maxLengthvalue = " + size.max() + "/>"
>>>>>>
>>>>>> * @Min - "<xs:minInclusive value = " + min.value() + "/>"
>>>>>>
>>>>>> * @Min - "<xs:maxInclusive value = " + max.value() + "/>"
>>>>>>
>>>>>> * @Pattern - <xs:pattern value=" + pattern.regexp() + " />"
>>>>>>
>>>>>> For adding bean-validation-support to the complex types the JAXB
>>>>>> processing / schema has to be parsed/filtered.
>>>>>>
>>>>>> The Java to schema mappings seems to be done here in
>>>>>> WadlGenerator.java,
>>>>>> line 1541:
>>>>>> for (DOMResult r : JAXBUtils.generateJaxbSchemas(context,
>>>>>> CastUtils.cast(Collections.emptyMap(),
>>>>>> String.class,
>>>>>> DOMResult.class))) {
>>>>>>
>>>>>> Am I correct in assuming we need a JAXB adapter which picks up the
>>>>>> beanvalidation-annotations?
>>>>>> https://docs.oracle.com/cd/E19316-01/819-3669/bnbdf/index.html
>>>>>>
>>>>>> So it seems we need to prepare the proper XmlAdapters
>>>>>> (https://docs.oracle.com/javase/7/docs/api/javax/xml/bind/annotation/adapters/XmlAdapter.html)
>>>>>>
>>>>>>
>>>>>>
>>>>>> to generate the necessary restrictions in the schema.
>>>>>>
>>>>>> However, it would also be nice to also add proper SimpleTypes and
>>>>>> reference them from the complexTypes (e.g. simpleType string_50
>>>>>> for a
>>>>>> string with a maximum of 50).
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Johannes
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: WadlGenerator - Bean validation support for complex types?
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 08/09/16 10:11, Sergey Beryozkin wrote:
> Hi Johannes
>
> I'm sorry but I'm not seeing how this can be applied - you generate some
> schema types inside wadl:doc - it will never have a chance of any
> interoperability (non CXF wadl-to-java processing it) and looks like a
> 'perfect' hack :-) - I do appreciate your effort, thanks for that, but
> I'm not going to apply it.
Well, I guess I'm wrong on a point that wadl:doc contains a schema
fragment is a hack - wadl:doc can contain whatever is needed (though a
schema fragment without <schema> tags seems strange) but it would not be
symmetrical to a WADL-first case - so rather than trying this limited
check for a couple of BeanVal annotations (given that the annotation set
is open-ended) and then expecting a user to manually move it to a
grammar is not really working IMHO.
By the way, while the solution to a WADL first case I suggested earlier
is no more interoperable (introducing a WADL Cxf extension) - but it
would work both ways, one would generate an easy to process element
'typed' around bean validations and the source generator will have an
easy time processing it.
Sergey
>
> In the other thread we are discussing how starting from a WADL can
> somehow get Query (and indeed header/path) being BeanVal validated.
> The solution needs to work both ways. I.e - if we settle on the idea
> that a wadl:param refers to a complex grammar type then at least I can
> imagine that in a Java to WADL case somehow a Java class with Bean
> validations can be projected back into the grammar
>
> Cheers, Sergey
>
> On 08/09/16 08:41, J. Fiala wrote:
>> Hi Sergey,
>>
>> The point of the extension I did for the WadlGenerator (to add
>> simpletype restrictions to query parameters based on their
>> beanvalidation annotations - seee
>> https://github.com/apache/cxf/pull/146/files, WadlGenerator.java) is to
>> support developers who have an existing codebase with lots of
>> BeanValidation annotations already annotated in the method parameters.
>>
>> If they want to move these into a WADL contract it is really easy to
>> expose them first using the WadlGenerator and then pick the simpletype
>> restrictions and move them out to schema. If you don't have these in the
>> generated WADL, you have to do this from the code which is much more
>> work, doing this in the WADL only is much more fun.
>>
>> After this is done and the WADL is fine, of course they can switch to
>> use the contract WADL and expose this instead of the generated WADL
>> (this feature works great including all schema references, I've used it
>> with such a fine-tuned WADL, really nice and no work at all, maybe we
>> could enhance the documentation there that it is working immediately for
>> schema references as well without any additional configuration work -
>> see http://cxf.apache.org/docs/jaxrs-services-description.html,
>> currently it is a bit misleading because I initially thought I have to
>> set WadlGenerator.schemaLocations to use embedded schemas, but this is
>> actually not the case if schema include is used instead of xs:import!).
>>
>> Of course I can also add a switch to turn this off if someone really
>> doesn't like it, but I think this will be rarely the case.
>>
>> Best regards,
>>
>> Johannes
>>
>>
>> Am 18.08.2016 um 13:19 schrieb Sergey Beryozkin:
>>> Hi
>>>
>>> thanks for the explanation.
>>>
>>> On 18/08/16 11:57, J. Fiala wrote:
>>>> Hi,
>>>>
>>>> If I'm using BeanValidation-annotations in my model classes, they are
>>>> not picked up by the WADLGenerator and so are lost if I do code first
>>>> and I have to look them up and model them in the WADL manually.
>>>>
>>>> At least @NotNull support would be nice, because this is really easy to
>>>> do (see the PR).
>>>>
>>> WADLGenerator will set a required flag if it is 'int'/'boolean' as
>>> opposed to Boolean/Integer
>>>
>>>> The others are a bit more tricky as they have to be generated as inline
>>>> simpletypes and probably in the WADL would be replaced by existing
>>>> simpletypes in the WADL/schema, but at least the developer has the hint
>>>> there is a pattern/restriction in place.
>>>> I already implemented @Size/@Min/@Max/@Pattern so you just have to pull
>>>> it in.
>>> I'd rather prefer to avoid going into all these schema manipulations.
>>> These hints can me made available in WADL grammar directly - have you
>>> checked if JAXB annotations can be used to set some of those
>>> restrictions ? Another option: WADL generator can be configured with a
>>> prepared XML schema as opposed to generating it.
>>>>
>>>> So better support for the BeanValidation annotations makes code first a
>>>> lot easier and also extending an existing WADL using code first for new
>>>> model classes...
>>> thanks, Sergey
>>>>
>>>> Best regards,
>>>>
>>>> Johannes
>>>>
>>>>
>>>> Am 18.08.2016 um 00:29 schrieb Sergey Beryozkin:
>>>>> Hi
>>>>>
>>>>> Can you explain please what exactly the purpose of it can be ?
>>>>> WADL generator simply reports the model info by using a JAXB compiler
>>>>> to generate XML schema, I'm trying to figure out how does the bean
>>>>> validation can help here or what it can change
>>>>>
>>>>> Sergey
>>>>> On 17/08/16 18:18, J. Fiala wrote:
>>>>>> I added this PR for bean-validation-support for query parameters:
>>>>>> https://github.com/apache/cxf/pull/146
>>>>>>
>>>>>> This also adds the required-flag for params by supporting @NotNull
>>>>>> (see
>>>>>> related question here:
>>>>>> http://stackoverflow.com/questions/13968261/required-queryparam-in-jax-rs-and-what-to-do-in-their-absence).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Additionally the PR adds support for @Size, @Min/@Max and @Pattern to
>>>>>> the query parameters and will add the proper restrictions inline:
>>>>>>
>>>>>> * @NotNull - minOccurs="1"
>>>>>>
>>>>>> * @Size - "<xs:minLengthvalue = " + size.min() + "/>",
>>>>>> "<xs:maxLengthvalue = " + size.max() + "/>"
>>>>>>
>>>>>> * @Min - "<xs:minInclusive value = " + min.value() + "/>"
>>>>>>
>>>>>> * @Min - "<xs:maxInclusive value = " + max.value() + "/>"
>>>>>>
>>>>>> * @Pattern - <xs:pattern value=" + pattern.regexp() + " />"
>>>>>>
>>>>>> For adding bean-validation-support to the complex types the JAXB
>>>>>> processing / schema has to be parsed/filtered.
>>>>>>
>>>>>> The Java to schema mappings seems to be done here in
>>>>>> WadlGenerator.java,
>>>>>> line 1541:
>>>>>> for (DOMResult r : JAXBUtils.generateJaxbSchemas(context,
>>>>>> CastUtils.cast(Collections.emptyMap(),
>>>>>> String.class,
>>>>>> DOMResult.class))) {
>>>>>>
>>>>>> Am I correct in assuming we need a JAXB adapter which picks up the
>>>>>> beanvalidation-annotations?
>>>>>> https://docs.oracle.com/cd/E19316-01/819-3669/bnbdf/index.html
>>>>>>
>>>>>> So it seems we need to prepare the proper XmlAdapters
>>>>>> (https://docs.oracle.com/javase/7/docs/api/javax/xml/bind/annotation/adapters/XmlAdapter.html)
>>>>>>
>>>>>>
>>>>>>
>>>>>> to generate the necessary restrictions in the schema.
>>>>>>
>>>>>> However, it would also be nice to also add proper SimpleTypes and
>>>>>> reference them from the complexTypes (e.g. simpleType string_50 for a
>>>>>> string with a maximum of 50).
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Johannes
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: WadlGenerator - Bean validation support for complex types?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Johannes
I'm sorry but I'm not seeing how this can be applied - you generate some
schema types inside wadl:doc - it will never have a chance of any
interoperability (non CXF wadl-to-java processing it) and looks like a
'perfect' hack :-) - I do appreciate your effort, thanks for that, but
I'm not going to apply it.
In the other thread we are discussing how starting from a WADL can
somehow get Query (and indeed header/path) being BeanVal validated.
The solution needs to work both ways. I.e - if we settle on the idea
that a wadl:param refers to a complex grammar type then at least I can
imagine that in a Java to WADL case somehow a Java class with Bean
validations can be projected back into the grammar
Cheers, Sergey
On 08/09/16 08:41, J. Fiala wrote:
> Hi Sergey,
>
> The point of the extension I did for the WadlGenerator (to add
> simpletype restrictions to query parameters based on their
> beanvalidation annotations - seee
> https://github.com/apache/cxf/pull/146/files, WadlGenerator.java) is to
> support developers who have an existing codebase with lots of
> BeanValidation annotations already annotated in the method parameters.
>
> If they want to move these into a WADL contract it is really easy to
> expose them first using the WadlGenerator and then pick the simpletype
> restrictions and move them out to schema. If you don't have these in the
> generated WADL, you have to do this from the code which is much more
> work, doing this in the WADL only is much more fun.
>
> After this is done and the WADL is fine, of course they can switch to
> use the contract WADL and expose this instead of the generated WADL
> (this feature works great including all schema references, I've used it
> with such a fine-tuned WADL, really nice and no work at all, maybe we
> could enhance the documentation there that it is working immediately for
> schema references as well without any additional configuration work -
> see http://cxf.apache.org/docs/jaxrs-services-description.html,
> currently it is a bit misleading because I initially thought I have to
> set WadlGenerator.schemaLocations to use embedded schemas, but this is
> actually not the case if schema include is used instead of xs:import!).
>
> Of course I can also add a switch to turn this off if someone really
> doesn't like it, but I think this will be rarely the case.
>
> Best regards,
>
> Johannes
>
>
> Am 18.08.2016 um 13:19 schrieb Sergey Beryozkin:
>> Hi
>>
>> thanks for the explanation.
>>
>> On 18/08/16 11:57, J. Fiala wrote:
>>> Hi,
>>>
>>> If I'm using BeanValidation-annotations in my model classes, they are
>>> not picked up by the WADLGenerator and so are lost if I do code first
>>> and I have to look them up and model them in the WADL manually.
>>>
>>> At least @NotNull support would be nice, because this is really easy to
>>> do (see the PR).
>>>
>> WADLGenerator will set a required flag if it is 'int'/'boolean' as
>> opposed to Boolean/Integer
>>
>>> The others are a bit more tricky as they have to be generated as inline
>>> simpletypes and probably in the WADL would be replaced by existing
>>> simpletypes in the WADL/schema, but at least the developer has the hint
>>> there is a pattern/restriction in place.
>>> I already implemented @Size/@Min/@Max/@Pattern so you just have to pull
>>> it in.
>> I'd rather prefer to avoid going into all these schema manipulations.
>> These hints can me made available in WADL grammar directly - have you
>> checked if JAXB annotations can be used to set some of those
>> restrictions ? Another option: WADL generator can be configured with a
>> prepared XML schema as opposed to generating it.
>>>
>>> So better support for the BeanValidation annotations makes code first a
>>> lot easier and also extending an existing WADL using code first for new
>>> model classes...
>> thanks, Sergey
>>>
>>> Best regards,
>>>
>>> Johannes
>>>
>>>
>>> Am 18.08.2016 um 00:29 schrieb Sergey Beryozkin:
>>>> Hi
>>>>
>>>> Can you explain please what exactly the purpose of it can be ?
>>>> WADL generator simply reports the model info by using a JAXB compiler
>>>> to generate XML schema, I'm trying to figure out how does the bean
>>>> validation can help here or what it can change
>>>>
>>>> Sergey
>>>> On 17/08/16 18:18, J. Fiala wrote:
>>>>> I added this PR for bean-validation-support for query parameters:
>>>>> https://github.com/apache/cxf/pull/146
>>>>>
>>>>> This also adds the required-flag for params by supporting @NotNull
>>>>> (see
>>>>> related question here:
>>>>> http://stackoverflow.com/questions/13968261/required-queryparam-in-jax-rs-and-what-to-do-in-their-absence).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Additionally the PR adds support for @Size, @Min/@Max and @Pattern to
>>>>> the query parameters and will add the proper restrictions inline:
>>>>>
>>>>> * @NotNull - minOccurs="1"
>>>>>
>>>>> * @Size - "<xs:minLengthvalue = " + size.min() + "/>",
>>>>> "<xs:maxLengthvalue = " + size.max() + "/>"
>>>>>
>>>>> * @Min - "<xs:minInclusive value = " + min.value() + "/>"
>>>>>
>>>>> * @Min - "<xs:maxInclusive value = " + max.value() + "/>"
>>>>>
>>>>> * @Pattern - <xs:pattern value=" + pattern.regexp() + " />"
>>>>>
>>>>> For adding bean-validation-support to the complex types the JAXB
>>>>> processing / schema has to be parsed/filtered.
>>>>>
>>>>> The Java to schema mappings seems to be done here in
>>>>> WadlGenerator.java,
>>>>> line 1541:
>>>>> for (DOMResult r : JAXBUtils.generateJaxbSchemas(context,
>>>>> CastUtils.cast(Collections.emptyMap(),
>>>>> String.class,
>>>>> DOMResult.class))) {
>>>>>
>>>>> Am I correct in assuming we need a JAXB adapter which picks up the
>>>>> beanvalidation-annotations?
>>>>> https://docs.oracle.com/cd/E19316-01/819-3669/bnbdf/index.html
>>>>>
>>>>> So it seems we need to prepare the proper XmlAdapters
>>>>> (https://docs.oracle.com/javase/7/docs/api/javax/xml/bind/annotation/adapters/XmlAdapter.html)
>>>>>
>>>>>
>>>>> to generate the necessary restrictions in the schema.
>>>>>
>>>>> However, it would also be nice to also add proper SimpleTypes and
>>>>> reference them from the complexTypes (e.g. simpleType string_50 for a
>>>>> string with a maximum of 50).
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Johannes
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/