Thanks for the hint - now I added the schema type reference detection for minLength/maxLength/pattern as example in

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 as well if you don't want to support it.

Best regards,

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...

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:

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

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,

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="...."
maxLength="..." />

<wadl:param name="..." required="true" type="xs:integer">
   <cxf:beanValRestriction pattern="..." minInclusive="...."
maxInclusive="..." />

b) Also allow usage of types (I believe much better):

<wadl:param name="..." required="true"
type="xs:integer"><cxf:beanValRestriction type="mytype" /></wadl:param>… <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

What do you think?

Best regards,

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

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:
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,


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
interoperability (non CXF wadl-to-java processing it) and looks
like a
'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 idea
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

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,
is to
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 easy to
expose them first using the WadlGenerator and then pick the
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
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 -
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

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,


Am 18.08.2016 um 13:19 schrieb Sergey Beryozkin:

thanks for the explanation.

On 18/08/16 11:57, J. Fiala wrote:

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
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
simpletypes and probably in the WADL would be replaced by existing simpletypes in the WADL/schema, but at least the developer has the
there is a pattern/restriction in place.
I already implemented @Size/@Min/@Max/@Pattern so you just have to
it in.
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
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
model classes...
thanks, Sergey

Best regards,


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
@Pattern to
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 JAXB
processing / schema has to be parsed/filtered.

The Java to schema mappings seems to be done here in,
line 1541:
 for (DOMResult r : JAXBUtils.generateJaxbSchemas(context,
DOMResult.class))) {

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_50
for a
string with a maximum of 50).

Best regards,


Reply via email to