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
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.
Am 12.09.2016 um 12:10 schrieb Sergey Beryozkin:
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...
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:
I think we can use the simpletype restrictions as already
WadlGenerator and even use them in the SourceGenerator (wadl2java).
I implemented a draft for Size(min,max) and Pattern, can you take a
in the PR (see SourceGenerator.java)?
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.
Am 10.09.2016 um 21:41 schrieb J. Fiala:
1.) So we would have to map the complex types to the parameter list
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
<!-- required can be easily picked from @NotNull --->
<wadl:param name="..." required="true" type="xs:string">
<cxf:beanValRestriction pattern="..." minLength="...."
<wadl:param name="..." required="true" type="xs:integer">
<cxf:beanValRestriction pattern="..." minInclusive="...."
b) Also allow usage of types (I believe much better):
<wadl:param name="..." required="true"
<cxf:type name="mytype" pattern="..." minLength=".."
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
So we have both code first/contract first covered with a solution
which is easy to use and also supports existing codebases with
What do you think?
Am 08.09.2016 um 11:42 schrieb Sergey Beryozkin:
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
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
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 ?
On 08/09/16 10:22, J. Fiala wrote:
No problem, the solution you suggested is of course the better way
(and great if it will work both ways eventually...!!)
Am 08.09.2016 um 11:11 schrieb Sergey Beryozkin:
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
interoperability (non CXF wadl-to-java processing it) and looks
'perfect' hack :-) - I do appreciate your effort, thanks for that,
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
that a wadl:param refers to a complex grammar type then at least I
imagine that in a Java to WADL case somehow a Java class with Bean
validations can be projected back into the grammar
On 08/09/16 08:41, J. Fiala wrote:
The point of the extension I did for the WadlGenerator (to add
simpletype restrictions to query parameters based on their
beanvalidation annotations - seee
support developers who have an existing codebase with lots of
BeanValidation annotations already annotated in the method
If they want to move these into a WADL contract it is really
expose them first using the WadlGenerator and then pick the
restrictions and move them out to schema. If you don't have these
generated WADL, you have to do this from the code which is much
work, doing this in the WADL only is much more fun.
After this is done and the WADL is fine, of course they can
use the contract WADL and expose this instead of the generated
(this feature works great including all schema references, I've
with such a fine-tuned WADL, really nice and no work at all,
could enhance the documentation there that it is working
schema references as well without any additional configuration
currently it is a bit misleading because I initially thought I
set WadlGenerator.schemaLocations to use embedded schemas, but
actually not the case if schema include is used instead of
Of course I can also add a switch to turn this off if someone
doesn't like it, but I think this will be rarely the case.
Am 18.08.2016 um 13:19 schrieb Sergey Beryozkin:
thanks for the explanation.
On 18/08/16 11:57, J. Fiala wrote:
WADLGenerator will set a required flag if it is
If I'm using BeanValidation-annotations in my model classes,
not picked up by the WADLGenerator and so are lost if I do code
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
do (see the PR).
opposed to Boolean/Integer
The others are a bit more tricky as they have to be generated as
simpletypes and probably in the WADL would be replaced by
simpletypes in the WADL/schema, but at least the developer
there is a pattern/restriction in place.
I already implemented @Size/@Min/@Max/@Pattern so you just
I'd rather prefer to avoid going into all these schema
These hints can me made available in WADL grammar directly - have
checked if JAXB annotations can be used to set some of those
restrictions ? Another option: WADL generator can be configured
prepared XML schema as opposed to generating it.
So better support for the BeanValidation annotations makes code
lot easier and also extending an existing WADL using code first
Am 18.08.2016 um 00:29 schrieb Sergey Beryozkin:
Can you explain please what exactly the purpose of it can be ?
WADL generator simply reports the model info by using a JAXB
to generate XML schema, I'm trying to figure out how does the
validation can help here or what it can change
On 17/08/16 18:18, J. Fiala wrote:
I added this PR for bean-validation-support for query
This also adds the required-flag for params by supporting
related question here:
Additionally the PR adds support for @Size, @Min/@Max and
the query parameters and will add the proper restrictions
* @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
processing / schema has to be parsed/filtered.
The Java to schema mappings seems to be done here in
for (DOMResult r : JAXBUtils.generateJaxbSchemas(context,
Am I correct in assuming we need a JAXB adapter which picks up
So it seems we need to prepare the proper XmlAdapters
to generate the necessary restrictions in the schema.
However, it would also be nice to also add proper SimpleTypes
reference them from the complexTypes (e.g. simpleType
string with a maximum of 50).