at the WadlGenerator and
try to generate the parameter restrictions into a separate grammar.
Yes, it's great the talk has been accepted, looking forward to meet you in
Seville!
Best regards,
Johannes
--
View this message in context:
http://cxf.547215.n5.nabble.com/WadlGenerator-Bean-validation
the
whole BeanValidation into a separate utility class?).
Best regards,
Johannes
--
View this message in context:
http://cxf.547215.n5.nabble.com/WadlGenerator-Bean-validation-support-for-complex-types-tp5771709p5773183.html
Sent from the cxf-user mailing list archive at Nabble.com
regards,
Johannes
--
View this message in context:
http://cxf.547215.n5.nabble.com/WadlGenerator-Bean-validation-support-for-complex-types-tp5771709p5773183.html
Sent from the cxf-user mailing list archive at Nabble.com.
Sergey,
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
Johannes,
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
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
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)?
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
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
On 08/09/16 10:11, Sergey Beryozkin wrote:
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
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
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
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
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
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
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:
17 matches
Mail list logo