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
