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>…
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
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/
