Hi Andriy
Indeed, makes sense to keep it and consider extending CXF UserModel over
time to be a bit richer so that it can accommodate
Swagger/OpenApi/something else/ models...
Cheers, Sergey
On 29/12/17 17:13, Andriy Redko wrote:
Hi Sergey,
Got it, thanks a lot for explaining the context. So I guess, we could
keep it, right? There is a diff from older Swagger specs, but more or less,
the parser does the job. What do you think?
Best Regards,
Andriy Redko
SB> Hi Andriy
SB> The idea there was to support the dynamic creation of CXF JAX-RS
SB> endpoints from a given Swagger doc, i.e, support Swagger-first dev
SB> without the code-generation, by converting Swagger docs into CXF
SB> specific UserResource(s) which in turn can be used to initialize the
SB> endpoint...
SB> I've found UserResource can not entirely match swagger model, the
SB> original idea behind UserResource/etc is doc-ed here:
SB>
http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-RESTfulserviceswithoutannotations
SB> with the model/etc classes expected to be avail on the classpath
SB> Sergey
SB> On 29/12/17 16:35, Andriy Redko wrote:
Hi Sergey,
I am not sure actually it is needed, but I am trying to match our Swagger2
implementation
where we have/are using Swagger2ParseUtils. We have test cases for that as well
as it is being
used in system tests for parsing the spec and checking expectations. Does it
make sense?
Thanks.
Best Regards,
Andriy Redko
SB> Hi Andriy
SB> Just curious, why would this new module will need OpenApiParseUtils ?
SB> Thanks, Sergey
