Hi,
No problem, all I need is a quick confirmation if you like the solution,
then I can extend it to support more nested restrictions and polish
everything up (I'd suggest moving all the beanvalidation methods into a
separate utiltiy class).
After SourceGenerator is fine, I can take a look at
Hi
I'm sorry have not had much time to look into recently, being a bit
overwhelmed with the various tasks. I'll try to look deeper into it in a
week's time, I'll be on and off next week.
I saw your presentation being scheduled for Apache Con EU 2016, great,
may we we can also discuss few
Sergey,
Pls let me know what you think of my addition to the SourceGenerator.java
(https://github.com/apache/cxf/pull/146/files), then I can add support for
the other BeanValidation annotations and polish things up (maybe extract the
whole BeanValidation into a separate utility class?).
Best
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:
16 matches
Mail list logo
