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/
