cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: microprofile openapi @asf?
Date Sun, 24 Jun 2018 17:41:05 GMT
Hi guys,

opened several issues about the spec and a few of them are serious concerns
for me (others are easier):

1. https://github.com/eclipse/microprofile-open-api/issues/231
2. https://github.com/eclipse/microprofile-open-api/issues/230
3. https://github.com/eclipse/microprofile-open-api/issues/228

Seems like there was no time to think about an API so swagger was just
copied (and adapted to openapi) which leads to something quite inconsistent
for end users and also inconsistent with the platform.
It doesn't prevent us to implement it but would be great if some of you can
check out issues and potentially vote for them. There is no Strong API
stability requirement at microprofile so there is stilla  hope the API is
made simpler and usable by end users.

In short (if you don't want to open the links) the issues are:

1. YAML is mandatory but there is nothing standard to modelize it so it is
an internal of the implementation and the format is not user friendly until
you use something outside the spec
2. The model is using OpenAPI object graph but it is not integrated with
JSON-B so it is not (de)serializable correctly for end user. It also breaks
the JAXRS serialization since each single object of the graph will need a
custom message reader/writer to work (but the spec doesnt spec about that
so payloads will not be the expected ones, in particular if you send back
from a client which got OpenAPI instance some subgraph!)
3. There are 2 API in the spec: a builder one and an annotation driven one.
The builder is sufficient and associated with a startup event allows to
avoid the annotations need which just duplicates the builder 1-1 with very
few semantic differences for ref and map management.

In one sentence it means that the API could be easier, less ambiguous for
end users, the integration with the platform more consistent and that it is
a very simple investment and work. It just needs to be made portable
accross vendor.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 21 juin 2018 à 16:20, Raymond Auge <raymond.auge@liferay.com> a
écrit :

> Great!
>
>
> On Thu, Jun 21, 2018 at 10:12 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
>
>> @Raymond: the diff between CDI and OSGi will be where the OpenAPI
>> instance will be created mainly so very doable (aries can even import
>> G-openapi for that). Only diff which can be quite intrusive is that @G we
>> don't use plain reflection to enable CDI meta model to be mutated during
>> startup and therefore let the user configure most of the model instead of
>> hardcoding it, but it is not that hard to abstract so I'm very confident to
>> keep it abstracted and to support OSGi once we support the spec with CDI
>> (and why not supporting CDI in aries ;)).
>>
>
> Regarding supporting CDI in Aries ;) it should look pretty much like any
> normal CDI extension with a tiny amount of extra OSGi metadata and what I
> hope are very reasonable restrictions on how extensions provide beans, if
> any.
>
> Sincerely,
> - Ray
>
>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> Le jeu. 21 juin 2018 à 15:21, Raymond Auge <raymond.auge@liferay.com> a
>> écrit :
>>
>>> It would be _nice_ if we could figure out a way for this to be usable by
>>> Apache Aries JAXRS Whiteboard [1] which is an implementation of OSGi JAXRS
>>> Whiteboard [2].
>>>
>>> It would seem that a small SPI on the part of Geronimo's mp-openapi
>>> might be enough (so as not to pressure this up onto the mp spec).
>>>
>>> [1] https://github.com/apache/aries-jax-rs-whiteboard
>>> [2] https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html
>>>
>>>
>>> On Thu, Jun 21, 2018 at 9:06 AM, Mark Struberg <
>>> struberg@yahoo.de.invalid> wrote:
>>>
>>>> I think it fits well to geronimo.
>>>> The question is rather if CXF is fine with relying on CDI for openapi?
>>>> But since MicroProfile _requires_ CDI I think there is safe to assume
>>>> so.
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>> > Am 21.06.2018 um 09:59 schrieb Romain Manni-Bucau <
>>>> rmannibucau@gmail.com>:
>>>> >
>>>> > Hello guys,
>>>> >
>>>> > we created a repo for that and to be able to share what we do:
>>>> > https://gitbox.apache.org/repos/asf?p=geronimo-openapi.git
>>>> >
>>>> > I pushed a basic starting structure of the code. The big TODO is the
>>>> > conversion from the model (annotations) to OpenAPI instance (which
>>>> should
>>>> > be somewhere here
>>>> >
>>>> https://gitbox.apache.org/repos/asf?p=geronimo-openapi.git;a=blob;f=src/main/java/org/apache/geronimo/microprofile/openapi/impl/processor/AnnotationProcessor.java;h=141227b579495e2b072710fadb28f2d08ab07616;hb=HEAD
>>>> > or split in multiple "visitors" if desired).
>>>> >
>>>> > If anyone wants to help it is welcomed. Also note it is not too late
>>>> to
>>>> > change the project hosting or other details if there is some points
we
>>>> > missed until now.
>>>> >
>>>> > Romain Manni-Bucau
>>>> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>> > <https://rmannibucau.metawerx.net/> | Old Blog
>>>> > <http://rmannibucau.wordpress.com> | Github <
>>>> https://github.com/rmannibucau> |
>>>> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>> > <
>>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>> >
>>>> >
>>>> >
>>>> > Le mar. 19 juin 2018 à 07:39, Romain Manni-Bucau <
>>>> rmannibucau@gmail.com> a
>>>> > écrit :
>>>> >
>>>> >> Basically read metadata from AnnotatedTypes (cdi) used by jaxrs
cdi
>>>> >> extension. Im not yet sure i will need the extension itself or not
>>>> (doesnt
>>>> >> seem hard to not use it for that and would stay portable).
>>>> >>
>>>> >>
>>>> >> Le mar. 19 juin 2018 00:36, Andriy Redko <drreta@gmail.com>
a écrit
>>>> :
>>>> >>
>>>> >>> Hey Romain,
>>>> >>>
>>>> >>> Thanks for starting work on that. Indeed,
>>>> >>> https://issues.apache.org/jira/browse/CXF-7601 is
>>>> >>> opened but not started yet, sadly. So what is your plan / scope,
>>>> generate
>>>> >>> the OpenAPI 3.x
>>>> >>> specs from JAX-RS 2.1 metadata? Or someting else? May be we
could
>>>> also
>>>> >>> help you with that?
>>>> >>> Thanks!
>>>> >>>
>>>> >>> Best Regards,
>>>> >>>    Andriy Redko
>>>> >>>
>>>> >>> RMB> Independent, cdi based (not reflection based)
>>>> >>>
>>>> >>> RMB> Le lun. 18 juin 2018 22:34, John D. Ament <
>>>> johndament@apache.org> a
>>>> >>> écrit :
>>>> >>>
>>>> >>>>> If it's hosted at Geronimo will it be platform independent?
 Or
>>>> only
>>>> >>> work
>>>> >>>>> with CXF?
>>>> >>>
>>>> >>>>> On Mon, Jun 18, 2018, 3:30 PM Romain Manni-Bucau <
>>>> >>> rmannibucau@gmail.com>
>>>> >>>>> wrote:
>>>> >>>
>>>> >>>>>> Hi guys,
>>>> >>>>>>
>>>> >>>>>> I'm planning to implement microprofile-openapi at
geronimo (next
>>>> to
>>>> >>> other
>>>> >>>>>> microprofile specs) soon (probably beginning of
next month).
>>>> Before
>>>> >>> doing
>>>> >>>>>> so I wanted to get in touch with you to ensure it
was not already
>>>> >>> there
>>>> >>>>>> (@asf). I know CXF has a swagger impl but here,
we speak about a
>>>> new
>>>> >>> API
>>>> >>>>>> and I hope to make it dep free and aligned on other
geronimo
>>>> impls
>>>> >>>>>> (assuming jsonb+jaxrs+cdi is in the server already
which is very
>>>> >>>>> acceptable
>>>> >>>>>> for a MP server).
>>>> >>>>>>
>>>> >>>>>> Anything I should check before launching the project
or is the
>>>> road
>>>> >>> as
>>>> >>>>> open
>>>> >>>>>> as I think?
>>>> >>>>>>
>>>> >>>>>> Technical side note: compared to the MP rest client
which was way
>>>> >>> easier
>>>> >>>>> to
>>>> >>>>>> impl @cxf cause all the code was already there,
the openapi is
>>>> more
>>>> >>> based
>>>> >>>>>> on CDI than CXF internal model so not hosting it
@cxf is not an
>>>> >>> issue for
>>>> >>>>>> this one so don't feel any pressure please.
>>>> >>>>>>
>>>> >>>>>> Thanks,
>>>> >>>>>> Romain Manni-Bucau
>>>> >>>>>> @rmannibucau <https://twitter.com/rmannibucau>
|  Blog
>>>> >>>>>> <https://rmannibucau.metawerx.net/> | Old
Blog
>>>> >>>>>> <http://rmannibucau.wordpress.com> | Github
<
>>>> >>>>>> https://github.com/rmannibucau> |
>>>> >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau>
| Book
>>>> >>>>>> <
>>>> >>>>>>
>>>> >>>>>
>>>> >>>
>>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>> >>>>>>>
>>>> >>>>>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>>
>>>>
>>>
>>>
>>> --
>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>  (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>>  (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>>> (@OSGiAlliance)
>>>
>>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message