microprofile openapi @asf?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

microprofile openapi @asf?

Romain Manni-Bucau
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 |  Blog | Old BlogGithub | LinkedIn | Book
Reply | Threaded
Open this post in threaded view
|

Re: microprofile openapi @asf?

John D. Ament
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 <[hidden email]> 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>
Reply | Threaded
Open this post in threaded view
|

Re: microprofile openapi @asf?

Romain Manni-Bucau
Independent, cdi based (not reflection based)

Le lun. 18 juin 2018 22:34, John D. Ament <[hidden email]> 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 <[hidden email]>
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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: microprofile openapi @asf?

Andriy Redko
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 <[hidden email]> 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 <[hidden email]>
>> 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
>> > >
>> >


Reply | Threaded
Open this post in threaded view
|

Re: microprofile openapi @asf?

Romain Manni-Bucau
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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
>> > >
>> >


Reply | Threaded
Open this post in threaded view
|

Re: microprofile openapi @asf?

Romain Manni-Bucau
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 |  Blog | Old BlogGithub | LinkedIn | Book


Le mar. 19 juin 2018 à 07:39, Romain Manni-Bucau <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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
>> > >
>> >


Reply | Threaded
Open this post in threaded view
|

Re: microprofile openapi @asf?

Mark Struberg
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 <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <
>>> [hidden email]>
>>>>> 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
>>>>>>>
>>>>>>
>>>
>>>
>>>

Reply | Threaded
Open this post in threaded view
|

Re: microprofile openapi @asf?

Raymond Auge
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).



On Thu, Jun 21, 2018 at 9:06 AM, Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <
>>> [hidden email]>
>>>>> 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é (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
Reply | Threaded
Open this post in threaded view
|

Re: microprofile openapi @asf?

Romain Manni-Bucau
@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 ;)).

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 21 juin 2018 à 15:21, Raymond Auge <[hidden email]> 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).



On Thu, Jun 21, 2018 at 9:06 AM, Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <
>>> [hidden email]>
>>>>> 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é (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
Reply | Threaded
Open this post in threaded view
|

Re: microprofile openapi @asf?

Raymond Auge
Great!


On Thu, Jun 21, 2018 at 10:12 AM, Romain Manni-Bucau <[hidden email]> 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 |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 21 juin 2018 à 15:21, Raymond Auge <[hidden email]> 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).



On Thu, Jun 21, 2018 at 9:06 AM, Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <
>>> [hidden email]>
>>>>> 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é (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)



--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
Reply | Threaded
Open this post in threaded view
|

Re: microprofile openapi @asf?

Romain Manni-Bucau
Hi guys,

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


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 |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 21 juin 2018 à 16:20, Raymond Auge <[hidden email]> a écrit :
Great!


On Thu, Jun 21, 2018 at 10:12 AM, Romain Manni-Bucau <[hidden email]> 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 |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 21 juin 2018 à 15:21, Raymond Auge <[hidden email]> 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).



On Thu, Jun 21, 2018 at 9:06 AM, Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <
>>> [hidden email]>
>>>>> 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é (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)



--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
Reply | Threaded
Open this post in threaded view
|

Re: microprofile openapi @asf?

Andriy Redko
Hi Romain,

Just went through the issues and comment threads. I am not really involved in MP (sadly)
but the YAML+JSON discussion makes sense to me, at least from the platform perspective. JSON
should be a must, YAML is optional (although it is very popular in OpenAPI community). My personal
position regarding the builder vs annotations is a matter of choice / preference. There are
centainly pros and cons of both, valid arguments are listed. I don't think either of them is
perfect for everyone, supporting both options sounds like a good trade-off, let devs pick whatever
fits better to the particular project / context.

The issue related to model serialization takes unexpected turn towards https://github.com/OpenAPITools
project ... I don't know the full details but afaik these guys are forking Swagger projects (swagger-codegen notably)
and rebranding under OpenApiTools umbrella. I am working on the PR https://github.com/swagger-api/swagger-codegen-generators/pull/101 to replace code generation of old Swagger / OpenAPI 2.x with OpenAPI 3.x (since Apache CXF
supports that out of the box). If things work out here as expected, I would be happy to help to introduce MP part
(server stubs or/and client) as well.

Thanks.

Best Regards,
    Andriy Redko

RMB> Hi guys,

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

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

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

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

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

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

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


RMB> Le jeu. 21 juin 2018 à 16:20, Raymond Auge <[hidden email]> a
RMB> écrit :

>> Great!


>> On Thu, Jun 21, 2018 at 10:12 AM, Romain Manni-Bucau <
>> [hidden email]> 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 <[hidden email]> 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 <
>>>> [hidden email]> 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 <
>>>>> [hidden email]>:
>>>>> >
>>>>> > 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 <
>>>>> [hidden email]> 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 <[hidden email]> 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 <
>>>>> [hidden email]> 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 <
>>>>> >>> [hidden email]>
>>>>> >>>>> 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)


Reply | Threaded
Open this post in threaded view
|

Re: microprofile openapi @asf?

Romain Manni-Bucau


Le dim. 24 juin 2018 21:59, Andriy Redko <[hidden email]> a écrit :
Hi Romain,

Just went through the issues and comment threads. I am not really involved in MP (sadly)
but the YAML+JSON discussion makes sense to me, at least from the platform perspective. JSON
should be a must, YAML is optional (although it is very popular in OpenAPI community). My personal
position regarding the builder vs annotations is a matter of choice / preference. There are
centainly pros and cons of both, valid arguments are listed. I don't think either of them is
perfect for everyone, supporting both options sounds like a good trade-off, let devs pick whatever
fits better to the particular project / context.

It assumes the ee5 pattern and forgets the cdi/event ones. I agree it is not yet mainstream but it is a convergence opportunity. In particular when you see all the reference workarounds annotation require and an event/programmatic solution doesnt. It is a huge gain in practise if you have endpoints using the same models.

Kind of theory vs practise feedback probably.


The issue related to model serialization takes unexpected turn towards https://github.com/OpenAPITools
project ... I don't know the full details but afaik these guys are forking Swagger projects (swagger-codegen notably)
and rebranding under OpenApiTools umbrella. I am working on the PR https://github.com/swagger-api/swagger-codegen-generators/pull/101 to replace code generation of old Swagger / OpenAPI 2.x with OpenAPI 3.x (since Apache CXF
supports that out of the box). If things work out here as expected, I would be happy to help to introduce MP part
(server stubs or/and client) as well.

Yep. My concern here is that using a custom serializer leads to limit the spec usage to the spec endpoint. It is likely 20% only of the main usages so spec will likely be replaced by something else anyway if it stays as such :(.


Thanks.

Best Regards,
    Andriy Redko

RMB> Hi guys,

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

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

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

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

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

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

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


RMB> Le jeu. 21 juin 2018 à 16:20, Raymond Auge <[hidden email]> a
RMB> écrit :

>> Great!


>> On Thu, Jun 21, 2018 at 10:12 AM, Romain Manni-Bucau <
>> [hidden email]> 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 <[hidden email]> 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 <
>>>> [hidden email]> 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 <
>>>>> [hidden email]>:
>>>>> >
>>>>> > 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 <
>>>>> [hidden email]> 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 <[hidden email]> 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 <
>>>>> [hidden email]> 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 <
>>>>> >>> [hidden email]>
>>>>> >>>>> 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)