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/
