[GitHub] tomee issue #340: TOMEE-2289 microprofile openAPI example

[puneethps]

Github user puneethps commented on the issue:

https://github.com/apache/tomee/pull/340
  
I noticed one more difference from the spec and the implementation, what I 
understood from the spec was that there is supposed to be a components field in 
the yaml or the json if there is a schema annotation which I don't see in the 
generated output. I think this should also be raised as an issue.


---

[GitHub] tomee pull request #340: TOMEE-2289 microprofile openAPI example

[puneethps]

Github user puneethps commented on a diff in the pull request:

https://github.com/apache/tomee/pull/340#discussion_r244777643
  
--- Diff: examples/mp-openapi/README.adoc ---
@@ -0,0 +1,112 @@
+:index-group: MicroProfile
+:jbake-type: page
+:jbake-status: unpublished
+
+# Microprofile OpenAPI
+This is an example on how to use microprofile OpenAPI in TomEE.
+
+== Run the application:
+mvn clean install tomee:run 
+
+Within the application there is an endpoint that will give you weather 
based on day.
+
+== Request
+
+GET http://localhost:8080/mp-openapi/weather/status/{today}
+
+
+== Response
+
+{today} is a sunny day.
+
+
+== OpenAPI
+
+OpenAPI is a spec for natively producing OpenAPI v3 documents from JAX-RS 
applications. 
+There exists an endpoint /openApi which gives the OpenAPI document based 
on Accept request header.
+
+
+== Request
+
+GET http://localhost:8080/mp-openapi/openapi
--- End diff --

I think it is working as expected now, without the Accept:application/json 
header it is outputting a valid YAML. I think I should document that in the 
README file. 


---

[GitHub] tomee pull request #340: TOMEE-2289 microprofile openAPI example

[ivanjunckes]

Github user ivanjunckes commented on a diff in the pull request:

https://github.com/apache/tomee/pull/340#discussion_r244724535
  
--- Diff: examples/mp-openapi/README.adoc ---
@@ -0,0 +1,112 @@
+:index-group: MicroProfile
+:jbake-type: page
+:jbake-status: unpublished
+
+# Microprofile OpenAPI
+This is an example on how to use microprofile OpenAPI in TomEE.
+
+== Run the application:
+mvn clean install tomee:run 
+
+Within the application there is an endpoint that will give you weather 
based on day.
+
+== Request
+
+GET http://localhost:8080/mp-openapi/weather/status/{today}
+
+
+== Response
+
+{today} is a sunny day.
+
+
+== OpenAPI
+
+OpenAPI is a spec for natively producing OpenAPI v3 documents from JAX-RS 
applications. 
+There exists an endpoint /openApi which gives the OpenAPI document based 
on Accept request header.
+
+
+== Request
+
+GET http://localhost:8080/mp-openapi/openapi
--- End diff --

It does not work without content-type as application/json so it is worth 
mention it. This is a bug in openapi I think. Because it should have a default 
message body reader/writer and it should be yaml. But it can be fixed later, 
there is a discussion on the list about it.


---

[GitHub] tomee pull request #340: TOMEE-2289 microprofile openAPI example

[ivanjunckes]

Github user ivanjunckes commented on a diff in the pull request:

https://github.com/apache/tomee/pull/340#discussion_r244725387
  
--- Diff: 
examples/mp-openapi/src/main/java/org/superbiz/openapi/WeatherService.java ---
@@ -0,0 +1,52 @@
+package org.superbiz.openapi;
+
+
+
+import javax.enterprise.context.ApplicationScoped;
+
+import javax.ws.rs.GET;
+import javax.ws.rs.Path;
+import javax.ws.rs.PathParam;
+import javax.ws.rs.core.Response;
+
+import org.eclipse.microprofile.openapi.annotations.Operation;
+import org.eclipse.microprofile.openapi.annotations.parameters.Parameter;
+import org.eclipse.microprofile.openapi.annotations.responses.APIResponse;
+import org.eclipse.microprofile.openapi.annotations.media.Content;
+import org.eclipse.microprofile.openapi.annotations.media.Schema;
+
--- End diff --

Can you be careful formatting the class? There are a lot of unnecessary 
spaces.


---

[GitHub] tomee pull request #340: TOMEE-2289 microprofile openAPI example

[ivanjunckes]

Github user ivanjunckes commented on a diff in the pull request:

https://github.com/apache/tomee/pull/340#discussion_r244725773
  
--- Diff: 
examples/mp-openapi/src/main/java/org/superbiz/openapi/WeatherService.java ---
@@ -0,0 +1,52 @@
+package org.superbiz.openapi;
+
+
+
+import javax.enterprise.context.ApplicationScoped;
+
+import javax.ws.rs.GET;
+import javax.ws.rs.Path;
+import javax.ws.rs.PathParam;
+import javax.ws.rs.core.Response;
+
+import org.eclipse.microprofile.openapi.annotations.Operation;
+import org.eclipse.microprofile.openapi.annotations.parameters.Parameter;
+import org.eclipse.microprofile.openapi.annotations.responses.APIResponse;
+import org.eclipse.microprofile.openapi.annotations.media.Content;
+import org.eclipse.microprofile.openapi.annotations.media.Schema;
+
+
+
+
+
+@Path("/weather")
+@ApplicationScoped
+public class WeatherService {
+
+@Path("/status/{day}/")   
+@GET
+@Operation(summary = "Finds weather for day specified in the URL ", 
description = "Describes how the day will be.")
+@APIResponse(responseCode = "400", description = "Weather for this day 
not found")
+public Response dayStatus( @Parameter(description = "The day for which 
the weather needs to be fetched.", required = true) @PathParam("day") String 
day) {
+   
+   if(day.equalsIgnoreCase("tomorrow"))
+   return 
Response.status(Response.Status.NOT_FOUND).build();
+   String message=day+ "is a sunny day.";
+return Response.status(Response.Status.OK)
+ .entity(message)
+ .build(); 
+}
+
+@Path("/detailedWeather/{day}/")   
+@GET
+@APIResponse(description = "Detailed Weather", 
content=@Content(mediaType="application/json", schema= 
@Schema(implementation=Weather.class)))
+public Weather getDetailedWeather( @Parameter(description = "The day 
for which the detailed weather needs to be fetched.", required = true) 
@PathParam("day") String day) {
+   
+Weather w=new Weather();
--- End diff --

Space is missing in several places, between variable and value assingments. 
Please format the class correctly.


---

[GitHub] tomee pull request #340: TOMEE-2289 microprofile openAPI example

[ivanjunckes]

Github user ivanjunckes commented on a diff in the pull request:

https://github.com/apache/tomee/pull/340#discussion_r244725584
  
--- Diff: 
examples/mp-openapi/src/main/java/org/superbiz/openapi/Weather.java ---
@@ -0,0 +1,25 @@
+package org.superbiz.openapi;
+
+import org.eclipse.microprofile.openapi.annotations.media.Schema;
+
+@Schema(name="Weather", description="POJO that represents weather.")
--- End diff --

Can you follow a pattern with spaces? name="Wather" has no space between 
name and the value. But for @Schema the variables have space. Can you make sure 
to format them correctly having one space between the variable and the value?


---

[GitHub] tomee pull request #340: TOMEE-2289 microprofile openAPI example

[ivanjunckes]

Github user ivanjunckes commented on a diff in the pull request:

https://github.com/apache/tomee/pull/340#discussion_r244723832
  
--- Diff: 
examples/mp-openapi/src/main/java/org/superbiz/openapi/WeatherService.java ---
@@ -0,0 +1,52 @@
+package org.superbiz.openapi;
+
+
+
+import javax.enterprise.context.ApplicationScoped;
+
+import javax.ws.rs.GET;
+import javax.ws.rs.Path;
+import javax.ws.rs.PathParam;
+import javax.ws.rs.core.Response;
+
+import org.eclipse.microprofile.openapi.annotations.Operation;
+import org.eclipse.microprofile.openapi.annotations.parameters.Parameter;
+import org.eclipse.microprofile.openapi.annotations.responses.APIResponse;
+import org.eclipse.microprofile.openapi.annotations.media.Content;
+import org.eclipse.microprofile.openapi.annotations.media.Schema;
+
+
+
+
+
+@Path("/weather")
+@ApplicationScoped
+public class WeatherService {
+
+@Path("/status/{day}/")   
+@GET
+@Operation(summary = "Finds weather for day specified in the URL ", 
description = "Describes how the day will be.")
+@APIResponse(responseCode = "400", description = "Weather for this day 
not found")
+public Response dayStatus( @Parameter(description = "The day for which 
the weather needs to be fetched.", required = true) @PathParam("day") String 
day) {
+   
+   if(day.equalsIgnoreCase("tomorrow"))
+   return 
Response.status(Response.Status.NOT_FOUND).build();
+   String message=day+ "is a sunny day.";
--- End diff --

It is missing a space. Output is "Mondayis a sunny day." and should be 
"Monday is a sunny day."


---

[GitHub] tomee pull request #340: TOMEE-2289 microprofile openAPI example

[ivanjunckes]

Github user ivanjunckes commented on a diff in the pull request:

https://github.com/apache/tomee/pull/340#discussion_r244724385
  
--- Diff: examples/mp-openapi/README.adoc ---
@@ -0,0 +1,112 @@
+:index-group: MicroProfile
+:jbake-type: page
+:jbake-status: unpublished
+
+# Microprofile OpenAPI
+This is an example on how to use microprofile OpenAPI in TomEE.
+
+== Run the application:
+mvn clean install tomee:run 
+
+Within the application there is an endpoint that will give you weather 
based on day.
+
+== Request
+
+GET http://localhost:8080/mp-openapi/weather/status/{today}
+
+
+== Response
+
+{today} is a sunny day.
+
+
+== OpenAPI
+
+OpenAPI is a spec for natively producing OpenAPI v3 documents from JAX-RS 
applications. 
+There exists an endpoint /openApi which gives the OpenAPI document based 
on Accept request header.
--- End diff --

"/openApi" is not a valid path, it must be "/openapi". Path is 
casesensitive.


---

[GitHub] tomee pull request #340: TOMEE-2289 microprofile openAPI example

[puneethps]

GitHub user puneethps opened a pull request:

https://github.com/apache/tomee/pull/340

TOMEE-2289 microprofile openAPI example

The JIRA status for TOMEE-2289 hasn't changed for quite sometime so I felt 
I could add a new project for this. Can someone please  review the PR and 
suggest changes required?

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/puneethps/tomee master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tomee/pull/340.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #340


commit cb3cc174ea9e66a63629b46f33a7f88b2bcedfd0
Author: Puneeth PS 
Date:   2019-01-01T11:34:21Z

Added MicroProfile OpenAPI Example.(TOMEE-2289)

There was no progress on TOMEE-2289 so I created the example project.

commit df1920931e0a19f1dc41edc6170f87ba42feadf2
Author: Puneeth PS 
Date:   2019-01-01T12:09:50Z

added README.adoc

added README.adoc




---

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

nibu...@gmail.com>
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >>> If jackson yaml is present it will add a (jackson) writer for
> > > yaml,
> > > > > if
> > > > > > >>> not it stays on json.
> > > > > > >>>
> > > > > > >>> 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 ven. 30 nov. 2018 à 16:51, Ivan Junckes Filho <
> > > > > > ivanjunc...@gmail.com>
> > > > > > >>> a écrit :
> > > > > > >>>
> > > > > > >>>> @Romain Manni-Bucau  not sure I
> > > understood
> > > > > > you.
> > > > > > >>>> Are you saying you will work to make it compatible with the
> > > spec?
> > > > > > Have yaml
> > > > > > >>>> as default?
> > > > > > >>>>
> > > > > > >>>> On Fri, Nov 30, 2018 at 1:30 PM César Hernández Mendoza <
> > > > > > >>>> cesargu...@gmail.com> wrote:
> > > > > > >>>>
> > > > > > >>>>> >
> > > > > > >>>>> > I think regardless of what the MicroProfile team decides,
> > we
> > > > need
> > > > > > to
> > > > > > >>>>> make
> > > > > > >>>>> > it work as the specification says. Then iterate from
> there.
> > > > > > >>>>> > In my opinion this is a big problem that makes us
> strongly
> > > > > > >>>>> incompatible
> > > > > > >>>>> > with the standard.
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>> +1
> > > > > > >>>>>
> > > > > > >>>>> El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<
> > > > > > >>>>> ivanjunc...@gmail.com>)
> > > > > > >>>>> escribió:
> > > > > > >>>>>
> > > > > > >>>>> > I think regardless of what the MicroProfile team decides,
> > we
> > > > need
> > > > > > to
> > > > > > >>>>> make
> > > > > > >>>>> > it work as the specification says. Then iterate from
> there.
> > > > > > >>>>> >
> > > > > > >>>>> > In my opinion this is a big problem that makes us
> strongly
> > > > > > >>>>> incompatible
> > > > > > >>>>> > with the standard.
> > > > > > >>>>> >
> > > > > > >>>>> > On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <
> > > > > > >>>>> rmannibu...@gmail.com>
> > > > > > >>>>> > wrote:
> > > > > > >>>>> >
> > > > > > >>>>> > > Browser and all clients default to */* or octect/stream
> > so
> > > > the
> > > > > > >>>>> else is
> > > > > > >>>>> > > never used normally and was here just to put a mimetype
> > > from
> > > > an
> > > > > > >>>>> optional.
> > > > > > >>>>> > >
> > > > > > >>>>> > > Browsers even send a kind of "all you can" value (*/*,
> >

Re: Microprofile OpenAPI

[César Hernández Mendoza]

compatible with the
> > spec?
> > > > > Have yaml
> > > > > >>>> as default?
> > > > > >>>>
> > > > > >>>> On Fri, Nov 30, 2018 at 1:30 PM César Hernández Mendoza <
> > > > > >>>> cesargu...@gmail.com> wrote:
> > > > > >>>>
> > > > > >>>>> >
> > > > > >>>>> > I think regardless of what the MicroProfile team decides,
> we
> > > need
> > > > > to
> > > > > >>>>> make
> > > > > >>>>> > it work as the specification says. Then iterate from there.
> > > > > >>>>> > In my opinion this is a big problem that makes us strongly
> > > > > >>>>> incompatible
> > > > > >>>>> > with the standard.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> +1
> > > > > >>>>>
> > > > > >>>>> El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<
> > > > > >>>>> ivanjunc...@gmail.com>)
> > > > > >>>>> escribió:
> > > > > >>>>>
> > > > > >>>>> > I think regardless of what the MicroProfile team decides,
> we
> > > need
> > > > > to
> > > > > >>>>> make
> > > > > >>>>> > it work as the specification says. Then iterate from there.
> > > > > >>>>> >
> > > > > >>>>> > In my opinion this is a big problem that makes us strongly
> > > > > >>>>> incompatible
> > > > > >>>>> > with the standard.
> > > > > >>>>> >
> > > > > >>>>> > On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <
> > > > > >>>>> rmannibu...@gmail.com>
> > > > > >>>>> > wrote:
> > > > > >>>>> >
> > > > > >>>>> > > Browser and all clients default to */* or octect/stream
> so
> > > the
> > > > > >>>>> else is
> > > > > >>>>> > > never used normally and was here just to put a mimetype
> > from
> > > an
> > > > > >>>>> optional.
> > > > > >>>>> > >
> > > > > >>>>> > > Browsers even send a kind of "all you can" value (*/*,
> > html,
> > > > xml
> > > > > at
> > > > > >>>>> > least).
> > > > > >>>>> > >
> > > > > >>>>> > > So yes we can make this value confifurable but this never
> > > > > happens.
> > > > > >>>>> Ivan's
> > > > > >>>>> > > case was even with cxf client which sets a value normally
> > by
> > > > > >>>>> default so
> > > > > >>>>> > it
> > > > > >>>>> > > wouldnt help I think.
> > > > > >>>>> > >
> > > > > >>>>> > > Le ven. 30 nov. 2018 06:21, John D. Ament <
> > > > johndam...@apache.org
> > > > > >
> > > > > >>>>> a
> > > > > >>>>> > écrit
> > > > > >>>>> > > :
> > > > > >>>>> > >
> > > > > >>>>> > > > The question posed to the MP team does not really match
> > the
> > > > > >>>>> question
> > > > > >>>>> > > > posted here, and seems to be a tangental ask.
> > > > > >>>>> > > >
> > > > > >>>>> > > > The problem is this line of code [1], and nothing to do
> > > with
> > > > > >>>>> TomEE's
> > > > > >>>>> > > > behavior; it defaults to JSON even though the spec
> states
> > > it
> > > > > >>>>> should be
> > > > > >>>>> > > > YAML.  Perhaps a clean solution would be to make this a
> > > > config
> > > > > >>>>> setting?
> > > > > >>>>> > > > But seems like there's a missing TCK test as well.  I'd
> > > also
> > > > > >>>>> question
> > > > > >>>>> > > when
> > > > > >>>>> > > > a browser goes here, what does it send in the Accepts
> > > header.
> > > > > >>>>> My guess
> > > > > >>>>> > > is
> > > > > >>>>> > > > most modern browsers send text/html which also wouldn't
> > > line
> > > > > up.
> > > > > >>>>> > > >
> > > > > >>>>> > > > John
> > > > > >>>>> > > >
> > > > > >>>>> > > > [1]:
> > > > > >>>>> > > >
> > > > > >>>>> > >
> > > > > >>>>> >
> > > > > >>>>>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
> > > > > >>>>> > > >
> > > > > >>>>> > > > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
> > > > > >>>>> > > rmannibu...@gmail.com>
> > > > > >>>>> > > > wrote:
> > > > > >>>>> > > >
> > > > > >>>>> > > >> Response is fine (thanks jaxrs), request is up to
> jaxrs
> > > > > runtime
> > > > > >>>>> so
> > > > > >>>>> > > >> depends where you deploy it (i dont think
> implementing a
> > > > > custom
> > > > > >>>>> writer
> > > > > >>>>> > > for
> > > > > >>>>> > > >> that is right for users, it has too much pitfalls once
> > > > > >>>>> integrated to
> > > > > >>>>> > > >> anything else than this very specific spec).
> > > > > >>>>> > > >>
> > > > > >>>>> > > >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
> > > > > >>>>> > > >> jonathan.gallim...@gmail.com> a écrit :
> > > > > >>>>> > > >>
> > > > > >>>>> > > >>> If the spec requires that, then I'd expect to get a
> > YAML
> > > > > >>>>> response if
> > > > > >>>>> > > >>> making a request without an `Accept` header on the
> > > request.
> > > > > >>>>> > > >>>
> > > > > >>>>> > > >>> I haven't looked through the microprofile-openapi
> TCK,
> > > but
> > > > > I'd
> > > > > >>>>> expect
> > > > > >>>>> > > >>> that to be tested, and I'd suggest contributing a
> test
> > > > there
> > > > > >>>>> if there
> > > > > >>>>> > > isn't
> > > > > >>>>> > > >>> one.
> > > > > >>>>> > > >>>
> > > > > >>>>> > > >>> If you wanted to explicitly request a YAML response,
> > I'd
> > > > > >>>>> expect one
> > > > > >>>>> > of
> > > > > >>>>> > > >>> these to work:
> > > > > >>>>> > > >>>
> > > > > >>>>> > > >>> Accept: application/x-yaml
> > > > > >>>>> > > >>> Accept: text/yaml
> > > > > >>>>> > > >>>
> > > > > >>>>> > > >>> I'd expect a Content-Type header on the response to
> > > > identify
> > > > > >>>>> the mime
> > > > > >>>>> > > >>> type of the response, whatever is being returned.
> > > > > >>>>> > > >>>
> > > > > >>>>> > > >>> Jon
> > > > > >>>>> > > >>>
> > > > > >>>>> > > >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
> > > > > >>>>> > > >>> ivanjunc...@gmail.com> wrote:
> > > > > >>>>> > > >>>
> > > > > >>>>> > > >>>> Hey guys, I think I found a bug in OpenAPI
> > > implementation.
> > > > > >>>>> > > >>>>
> > > > > >>>>> > > >>>> The spec says:
> > > > > >>>>> > > >>>> "The default format of the /openapi endpoint is
> YAML."
> > > > > >>>>> > > >>>>
> > > > > >>>>> > > >>>> But when I try to access /openapi it returns JSON by
> > > > > default.
> > > > > >>>>> > > >>>>
> > > > > >>>>> > > >>>> This is not correct.
> > > > > >>>>> > > >>>>
> > > > > >>>>> > > >>>> Also how can I access yaml if it is not default?
> > > > > >>>>> > > >>>>
> > > > > >>>>> > > >>>
> > > > > >>>>> > >
> > > > > >>>>> >
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> --
> > > > > >>>>> Atentamente:
> > > > > >>>>> César Hernández Mendoza.
> > > > > >>>>>
> > > > > >>>>
> > > > >
> > > >
> > > >
> > > > --
> > > > Richard Monson-Haefel
> > > > https://twitter.com/rmonson
> > > > https://www.linkedin.com/in/monsonhaefel/
> > > >
> > >
> >
>


-- 
Atentamente:
César Hernández Mendoza.

Re: Microprofile OpenAPI

[Ivan Junckes Filho]

>>>> >
> > >>>>> > I think regardless of what the MicroProfile team decides, we need
> > to
> > >>>>> make
> > >>>>> > it work as the specification says. Then iterate from there.
> > >>>>> > In my opinion this is a big problem that makes us strongly
> > >>>>> incompatible
> > >>>>> > with the standard.
> > >>>>>
> > >>>>>
> > >>>>> +1
> > >>>>>
> > >>>>> El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<
> > >>>>> ivanjunc...@gmail.com>)
> > >>>>> escribió:
> > >>>>>
> > >>>>> > I think regardless of what the MicroProfile team decides, we need
> > to
> > >>>>> make
> > >>>>> > it work as the specification says. Then iterate from there.
> > >>>>> >
> > >>>>> > In my opinion this is a big problem that makes us strongly
> > >>>>> incompatible
> > >>>>> > with the standard.
> > >>>>> >
> > >>>>> > On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <
> > >>>>> rmannibu...@gmail.com>
> > >>>>> > wrote:
> > >>>>> >
> > >>>>> > > Browser and all clients default to */* or octect/stream so the
> > >>>>> else is
> > >>>>> > > never used normally and was here just to put a mimetype from an
> > >>>>> optional.
> > >>>>> > >
> > >>>>> > > Browsers even send a kind of "all you can" value (*/*, html,
> xml
> > at
> > >>>>> > least).
> > >>>>> > >
> > >>>>> > > So yes we can make this value confifurable but this never
> > happens.
> > >>>>> Ivan's
> > >>>>> > > case was even with cxf client which sets a value normally by
> > >>>>> default so
> > >>>>> > it
> > >>>>> > > wouldnt help I think.
> > >>>>> > >
> > >>>>> > > Le ven. 30 nov. 2018 06:21, John D. Ament <
> johndam...@apache.org
> > >
> > >>>>> a
> > >>>>> > écrit
> > >>>>> > > :
> > >>>>> > >
> > >>>>> > > > The question posed to the MP team does not really match the
> > >>>>> question
> > >>>>> > > > posted here, and seems to be a tangental ask.
> > >>>>> > > >
> > >>>>> > > > The problem is this line of code [1], and nothing to do with
> > >>>>> TomEE's
> > >>>>> > > > behavior; it defaults to JSON even though the spec states it
> > >>>>> should be
> > >>>>> > > > YAML.  Perhaps a clean solution would be to make this a
> config
> > >>>>> setting?
> > >>>>> > > > But seems like there's a missing TCK test as well.  I'd also
> > >>>>> question
> > >>>>> > > when
> > >>>>> > > > a browser goes here, what does it send in the Accepts header.
> > >>>>> My guess
> > >>>>> > > is
> > >>>>> > > > most modern browsers send text/html which also wouldn't line
> > up.
> > >>>>> > > >
> > >>>>> > > > John
> > >>>>> > > >
> > >>>>> > > > [1]:
> > >>>>> > > >
> > >>>>> > >
> > >>>>> >
> > >>>>>
> >
> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
> > >>>>> > > >
> > >>>>> > > > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
> > >>>>> > > rmannibu...@gmail.com>
> > >>>>> > > > wrote:
> > >>>>> > > >
> > >>>>> > > >> Response is fine (thanks jaxrs), request is up to jaxrs
> > runtime
> > >>>>> so
> > >>>>> > > >> depends where you deploy it (i dont think implementing a
> > custom
> > >>>>> writer
> > >>>>> > > for
> > >>>>> > > >> that is right for users, it has too much pitfalls once
> > >>>>> integrated to
> > >>>>> > > >> anything else than this very specific spec).
> > >>>>> > > >>
> > >>>>> > > >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
> > >>>>> > > >> jonathan.gallim...@gmail.com> a écrit :
> > >>>>> > > >>
> > >>>>> > > >>> If the spec requires that, then I'd expect to get a YAML
> > >>>>> response if
> > >>>>> > > >>> making a request without an `Accept` header on the request.
> > >>>>> > > >>>
> > >>>>> > > >>> I haven't looked through the microprofile-openapi TCK, but
> > I'd
> > >>>>> expect
> > >>>>> > > >>> that to be tested, and I'd suggest contributing a test
> there
> > >>>>> if there
> > >>>>> > > isn't
> > >>>>> > > >>> one.
> > >>>>> > > >>>
> > >>>>> > > >>> If you wanted to explicitly request a YAML response, I'd
> > >>>>> expect one
> > >>>>> > of
> > >>>>> > > >>> these to work:
> > >>>>> > > >>>
> > >>>>> > > >>> Accept: application/x-yaml
> > >>>>> > > >>> Accept: text/yaml
> > >>>>> > > >>>
> > >>>>> > > >>> I'd expect a Content-Type header on the response to
> identify
> > >>>>> the mime
> > >>>>> > > >>> type of the response, whatever is being returned.
> > >>>>> > > >>>
> > >>>>> > > >>> Jon
> > >>>>> > > >>>
> > >>>>> > > >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
> > >>>>> > > >>> ivanjunc...@gmail.com> wrote:
> > >>>>> > > >>>
> > >>>>> > > >>>> Hey guys, I think I found a bug in OpenAPI implementation.
> > >>>>> > > >>>>
> > >>>>> > > >>>> The spec says:
> > >>>>> > > >>>> "The default format of the /openapi endpoint is YAML."
> > >>>>> > > >>>>
> > >>>>> > > >>>> But when I try to access /openapi it returns JSON by
> > default.
> > >>>>> > > >>>>
> > >>>>> > > >>>> This is not correct.
> > >>>>> > > >>>>
> > >>>>> > > >>>> Also how can I access yaml if it is not default?
> > >>>>> > > >>>>
> > >>>>> > > >>>
> > >>>>> > >
> > >>>>> >
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Atentamente:
> > >>>>> César Hernández Mendoza.
> > >>>>>
> > >>>>
> >
>
>
> --
> Richard Monson-Haefel
> https://twitter.com/rmonson
> https://www.linkedin.com/in/monsonhaefel/
>

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

> > > > > Also to answer clearly to your question: I prefer to have an impl
> not
> > > > > compatible with the spec when the spec says something stupid, most
> of
> > > the
> > > > > time we put toggle to be able to be compatible but sometimes there
> is
> > > not
> > > > > even a way to be compatible, this is what has been done in TomEE
> > since
> > > > > years and it works well making users happy rather than spec leads.
> > > > >
> > > > > 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 ven. 30 nov. 2018 à 17:11, Ivan Junckes Filho <
> > > ivanjunc...@gmail.com>
> > > > > a écrit :
> > > > >
> > > > >> This is against the spec as well, yaml is required and must always
> > be
> > > > >> default. Do we really want to let our implementation not
> compatible
> > > with
> > > > >> that?
> > > > >>
> > > > >> On Fri, Nov 30, 2018 at 2:03 PM Romain Manni-Bucau <
> > > > rmannibu...@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >>> If jackson yaml is present it will add a (jackson) writer for
> yaml,
> > > if
> > > > >>> not it stays on json.
> > > > >>>
> > > > >>> 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 ven. 30 nov. 2018 à 16:51, Ivan Junckes Filho <
> > > > ivanjunc...@gmail.com>
> > > > >>> a écrit :
> > > > >>>
> > > > >>>> @Romain Manni-Bucau  not sure I
> understood
> > > > you.
> > > > >>>> Are you saying you will work to make it compatible with the
> spec?
> > > > Have yaml
> > > > >>>> as default?
> > > > >>>>
> > > > >>>> On Fri, Nov 30, 2018 at 1:30 PM César Hernández Mendoza <
> > > > >>>> cesargu...@gmail.com> wrote:
> > > > >>>>
> > > > >>>>> >
> > > > >>>>> > I think regardless of what the MicroProfile team decides, we
> > need
> > > > to
> > > > >>>>> make
> > > > >>>>> > it work as the specification says. Then iterate from there.
> > > > >>>>> > In my opinion this is a big problem that makes us strongly
> > > > >>>>> incompatible
> > > > >>>>> > with the standard.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> +1
> > > > >>>>>
> > > > >>>>> El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<
> > > > >>>>> ivanjunc...@gmail.com>)
> > > > >>>>> escribió:
> > > > >>>>>
> > > > >>>>> > I think regardless of what the MicroProfile team decides, we
> > need
> > > > to
> > > > >>>>> make
> > > > >>>>> > it work as the specification says. Then iterate from there.
> > > > >>>>> >
> > > > >>>>> > In my opinio

Re: Microprofile OpenAPI

[Ivan Junckes Filho]

 > >
> > > >
> > > > Le ven. 30 nov. 2018 à 17:11, Ivan Junckes Filho <
> > ivanjunc...@gmail.com>
> > > > a écrit :
> > > >
> > > >> This is against the spec as well, yaml is required and must always
> be
> > > >> default. Do we really want to let our implementation not compatible
> > with
> > > >> that?
> > > >>
> > > >> On Fri, Nov 30, 2018 at 2:03 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> If jackson yaml is present it will add a (jackson) writer for yaml,
> > if
> > > >>> not it stays on json.
> > > >>>
> > > >>> 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 ven. 30 nov. 2018 à 16:51, Ivan Junckes Filho <
> > > ivanjunc...@gmail.com>
> > > >>> a écrit :
> > > >>>
> > > >>>> @Romain Manni-Bucau  not sure I understood
> > > you.
> > > >>>> Are you saying you will work to make it compatible with the spec?
> > > Have yaml
> > > >>>> as default?
> > > >>>>
> > > >>>> On Fri, Nov 30, 2018 at 1:30 PM César Hernández Mendoza <
> > > >>>> cesargu...@gmail.com> wrote:
> > > >>>>
> > > >>>>> >
> > > >>>>> > I think regardless of what the MicroProfile team decides, we
> need
> > > to
> > > >>>>> make
> > > >>>>> > it work as the specification says. Then iterate from there.
> > > >>>>> > In my opinion this is a big problem that makes us strongly
> > > >>>>> incompatible
> > > >>>>> > with the standard.
> > > >>>>>
> > > >>>>>
> > > >>>>> +1
> > > >>>>>
> > > >>>>> El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<
> > > >>>>> ivanjunc...@gmail.com>)
> > > >>>>> escribió:
> > > >>>>>
> > > >>>>> > I think regardless of what the MicroProfile team decides, we
> need
> > > to
> > > >>>>> make
> > > >>>>> > it work as the specification says. Then iterate from there.
> > > >>>>> >
> > > >>>>> > In my opinion this is a big problem that makes us strongly
> > > >>>>> incompatible
> > > >>>>> > with the standard.
> > > >>>>> >
> > > >>>>> > On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <
> > > >>>>> rmannibu...@gmail.com>
> > > >>>>> > wrote:
> > > >>>>> >
> > > >>>>> > > Browser and all clients default to */* or octect/stream so
> the
> > > >>>>> else is
> > > >>>>> > > never used normally and was here just to put a mimetype from
> an
> > > >>>>> optional.
> > > >>>>> > >
> > > >>>>> > > Browsers even send a kind of "all you can" value (*/*, html,
> > xml
> > > at
> > > >>>>> > least).
> > > >>>>> > >
> > > >>>>> > > So yes we can make this value confifurable but this never
> > > happens.
> > > >>>>> Ivan's
> > > >>>>> > > case was even with cxf client which sets a value normally by
> > > >>>>> default so
> > > >>>>> > it
> > > >>>>> > > wouldnt help I think.
> > > >>>>> > >
> > > >>>>> > 

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

tible with the spec?
> > Have yaml
> > >>>> as default?
> > >>>>
> > >>>> On Fri, Nov 30, 2018 at 1:30 PM César Hernández Mendoza <
> > >>>> cesargu...@gmail.com> wrote:
> > >>>>
> > >>>>> >
> > >>>>> > I think regardless of what the MicroProfile team decides, we need
> > to
> > >>>>> make
> > >>>>> > it work as the specification says. Then iterate from there.
> > >>>>> > In my opinion this is a big problem that makes us strongly
> > >>>>> incompatible
> > >>>>> > with the standard.
> > >>>>>
> > >>>>>
> > >>>>> +1
> > >>>>>
> > >>>>> El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<
> > >>>>> ivanjunc...@gmail.com>)
> > >>>>> escribió:
> > >>>>>
> > >>>>> > I think regardless of what the MicroProfile team decides, we need
> > to
> > >>>>> make
> > >>>>> > it work as the specification says. Then iterate from there.
> > >>>>> >
> > >>>>> > In my opinion this is a big problem that makes us strongly
> > >>>>> incompatible
> > >>>>> > with the standard.
> > >>>>> >
> > >>>>> > On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <
> > >>>>> rmannibu...@gmail.com>
> > >>>>> > wrote:
> > >>>>> >
> > >>>>> > > Browser and all clients default to */* or octect/stream so the
> > >>>>> else is
> > >>>>> > > never used normally and was here just to put a mimetype from an
> > >>>>> optional.
> > >>>>> > >
> > >>>>> > > Browsers even send a kind of "all you can" value (*/*, html,
> xml
> > at
> > >>>>> > least).
> > >>>>> > >
> > >>>>> > > So yes we can make this value confifurable but this never
> > happens.
> > >>>>> Ivan's
> > >>>>> > > case was even with cxf client which sets a value normally by
> > >>>>> default so
> > >>>>> > it
> > >>>>> > > wouldnt help I think.
> > >>>>> > >
> > >>>>> > > Le ven. 30 nov. 2018 06:21, John D. Ament <
> johndam...@apache.org
> > >
> > >>>>> a
> > >>>>> > écrit
> > >>>>> > > :
> > >>>>> > >
> > >>>>> > > > The question posed to the MP team does not really match the
> > >>>>> question
> > >>>>> > > > posted here, and seems to be a tangental ask.
> > >>>>> > > >
> > >>>>> > > > The problem is this line of code [1], and nothing to do with
> > >>>>> TomEE's
> > >>>>> > > > behavior; it defaults to JSON even though the spec states it
> > >>>>> should be
> > >>>>> > > > YAML.  Perhaps a clean solution would be to make this a
> config
> > >>>>> setting?
> > >>>>> > > > But seems like there's a missing TCK test as well.  I'd also
> > >>>>> question
> > >>>>> > > when
> > >>>>> > > > a browser goes here, what does it send in the Accepts header.
> > >>>>> My guess
> > >>>>> > > is
> > >>>>> > > > most modern browsers send text/html which also wouldn't line
> > up.
> > >>>>> > > >
> > >>>>> > > > John
> > >>>>> > > >
> > >>>>> > > > [1]:
> > >>>>> > > >
> > >>>>> > >
> > >>>>> >
> > >>>>>
> >
> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
> > >>>>> > > >
> > >>>>> > > > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
> > >>>>> > > rmannibu...@gmail.com>
> > >>>>> > > > wrote:
> > >>>>> > > >
> > >>>>> > > >> Response is fine (thanks jaxrs), request is up to jaxrs
> > runtime
> > >>>>> so
> > >>>>> > > >> depends where you deploy it (i dont think implementing a
> > custom
> > >>>>> writer
> > >>>>> > > for
> > >>>>> > > >> that is right for users, it has too much pitfalls once
> > >>>>> integrated to
> > >>>>> > > >> anything else than this very specific spec).
> > >>>>> > > >>
> > >>>>> > > >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
> > >>>>> > > >> jonathan.gallim...@gmail.com> a écrit :
> > >>>>> > > >>
> > >>>>> > > >>> If the spec requires that, then I'd expect to get a YAML
> > >>>>> response if
> > >>>>> > > >>> making a request without an `Accept` header on the request.
> > >>>>> > > >>>
> > >>>>> > > >>> I haven't looked through the microprofile-openapi TCK, but
> > I'd
> > >>>>> expect
> > >>>>> > > >>> that to be tested, and I'd suggest contributing a test
> there
> > >>>>> if there
> > >>>>> > > isn't
> > >>>>> > > >>> one.
> > >>>>> > > >>>
> > >>>>> > > >>> If you wanted to explicitly request a YAML response, I'd
> > >>>>> expect one
> > >>>>> > of
> > >>>>> > > >>> these to work:
> > >>>>> > > >>>
> > >>>>> > > >>> Accept: application/x-yaml
> > >>>>> > > >>> Accept: text/yaml
> > >>>>> > > >>>
> > >>>>> > > >>> I'd expect a Content-Type header on the response to
> identify
> > >>>>> the mime
> > >>>>> > > >>> type of the response, whatever is being returned.
> > >>>>> > > >>>
> > >>>>> > > >>> Jon
> > >>>>> > > >>>
> > >>>>> > > >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
> > >>>>> > > >>> ivanjunc...@gmail.com> wrote:
> > >>>>> > > >>>
> > >>>>> > > >>>> Hey guys, I think I found a bug in OpenAPI implementation.
> > >>>>> > > >>>>
> > >>>>> > > >>>> The spec says:
> > >>>>> > > >>>> "The default format of the /openapi endpoint is YAML."
> > >>>>> > > >>>>
> > >>>>> > > >>>> But when I try to access /openapi it returns JSON by
> > default.
> > >>>>> > > >>>>
> > >>>>> > > >>>> This is not correct.
> > >>>>> > > >>>>
> > >>>>> > > >>>> Also how can I access yaml if it is not default?
> > >>>>> > > >>>>
> > >>>>> > > >>>
> > >>>>> > >
> > >>>>> >
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Atentamente:
> > >>>>> César Hernández Mendoza.
> > >>>>>
> > >>>>
> >
>
>
> --
> Richard Monson-Haefel
> https://twitter.com/rmonson
> https://www.linkedin.com/in/monsonhaefel/
>

Re: Microprofile OpenAPI

[Richard Monson-Haefel]

file team decides, we need
> to
> >>>>> make
> >>>>> > it work as the specification says. Then iterate from there.
> >>>>> >
> >>>>> > In my opinion this is a big problem that makes us strongly
> >>>>> incompatible
> >>>>> > with the standard.
> >>>>> >
> >>>>> > On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <
> >>>>> rmannibu...@gmail.com>
> >>>>> > wrote:
> >>>>> >
> >>>>> > > Browser and all clients default to */* or octect/stream so the
> >>>>> else is
> >>>>> > > never used normally and was here just to put a mimetype from an
> >>>>> optional.
> >>>>> > >
> >>>>> > > Browsers even send a kind of "all you can" value (*/*, html, xml
> at
> >>>>> > least).
> >>>>> > >
> >>>>> > > So yes we can make this value confifurable but this never
> happens.
> >>>>> Ivan's
> >>>>> > > case was even with cxf client which sets a value normally by
> >>>>> default so
> >>>>> > it
> >>>>> > > wouldnt help I think.
> >>>>> > >
> >>>>> > > Le ven. 30 nov. 2018 06:21, John D. Ament  >
> >>>>> a
> >>>>> > écrit
> >>>>> > > :
> >>>>> > >
> >>>>> > > > The question posed to the MP team does not really match the
> >>>>> question
> >>>>> > > > posted here, and seems to be a tangental ask.
> >>>>> > > >
> >>>>> > > > The problem is this line of code [1], and nothing to do with
> >>>>> TomEE's
> >>>>> > > > behavior; it defaults to JSON even though the spec states it
> >>>>> should be
> >>>>> > > > YAML.  Perhaps a clean solution would be to make this a config
> >>>>> setting?
> >>>>> > > > But seems like there's a missing TCK test as well.  I'd also
> >>>>> question
> >>>>> > > when
> >>>>> > > > a browser goes here, what does it send in the Accepts header.
> >>>>> My guess
> >>>>> > > is
> >>>>> > > > most modern browsers send text/html which also wouldn't line
> up.
> >>>>> > > >
> >>>>> > > > John
> >>>>> > > >
> >>>>> > > > [1]:
> >>>>> > > >
> >>>>> > >
> >>>>> >
> >>>>>
> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
> >>>>> > > >
> >>>>> > > > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
> >>>>> > > rmannibu...@gmail.com>
> >>>>> > > > wrote:
> >>>>> > > >
> >>>>> > > >> Response is fine (thanks jaxrs), request is up to jaxrs
> runtime
> >>>>> so
> >>>>> > > >> depends where you deploy it (i dont think implementing a
> custom
> >>>>> writer
> >>>>> > > for
> >>>>> > > >> that is right for users, it has too much pitfalls once
> >>>>> integrated to
> >>>>> > > >> anything else than this very specific spec).
> >>>>> > > >>
> >>>>> > > >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
> >>>>> > > >> jonathan.gallim...@gmail.com> a écrit :
> >>>>> > > >>
> >>>>> > > >>> If the spec requires that, then I'd expect to get a YAML
> >>>>> response if
> >>>>> > > >>> making a request without an `Accept` header on the request.
> >>>>> > > >>>
> >>>>> > > >>> I haven't looked through the microprofile-openapi TCK, but
> I'd
> >>>>> expect
> >>>>> > > >>> that to be tested, and I'd suggest contributing a test there
> >>>>> if there
> >>>>> > > isn't
> >>>>> > > >>> one.
> >>>>> > > >>>
> >>>>> > > >>> If you wanted to explicitly request a YAML response, I'd
> >>>>> expect one
> >>>>> > of
> >>>>> > > >>> these to work:
> >>>>> > > >>>
> >>>>> > > >>> Accept: application/x-yaml
> >>>>> > > >>> Accept: text/yaml
> >>>>> > > >>>
> >>>>> > > >>> I'd expect a Content-Type header on the response to identify
> >>>>> the mime
> >>>>> > > >>> type of the response, whatever is being returned.
> >>>>> > > >>>
> >>>>> > > >>> Jon
> >>>>> > > >>>
> >>>>> > > >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
> >>>>> > > >>> ivanjunc...@gmail.com> wrote:
> >>>>> > > >>>
> >>>>> > > >>>> Hey guys, I think I found a bug in OpenAPI implementation.
> >>>>> > > >>>>
> >>>>> > > >>>> The spec says:
> >>>>> > > >>>> "The default format of the /openapi endpoint is YAML."
> >>>>> > > >>>>
> >>>>> > > >>>> But when I try to access /openapi it returns JSON by
> default.
> >>>>> > > >>>>
> >>>>> > > >>>> This is not correct.
> >>>>> > > >>>>
> >>>>> > > >>>> Also how can I access yaml if it is not default?
> >>>>> > > >>>>
> >>>>> > > >>>
> >>>>> > >
> >>>>> >
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Atentamente:
> >>>>> César Hernández Mendoza.
> >>>>>
> >>>>
>


-- 
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.linkedin.com/in/monsonhaefel/

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

 > with the standard.
>>>>>>
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<
>>>>>> ivanjunc...@gmail.com>)
>>>>>> escribió:
>>>>>>
>>>>>> > I think regardless of what the MicroProfile team decides, we need
>>>>>> to make
>>>>>> > it work as the specification says. Then iterate from there.
>>>>>> >
>>>>>> > In my opinion this is a big problem that makes us strongly
>>>>>> incompatible
>>>>>> > with the standard.
>>>>>> >
>>>>>> > On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <
>>>>>> rmannibu...@gmail.com>
>>>>>> > wrote:
>>>>>> >
>>>>>> > > Browser and all clients default to */* or octect/stream so the
>>>>>> else is
>>>>>> > > never used normally and was here just to put a mimetype from an
>>>>>> optional.
>>>>>> > >
>>>>>> > > Browsers even send a kind of "all you can" value (*/*, html, xml
>>>>>> at
>>>>>> > least).
>>>>>> > >
>>>>>> > > So yes we can make this value confifurable but this never
>>>>>> happens. Ivan's
>>>>>> > > case was even with cxf client which sets a value normally by
>>>>>> default so
>>>>>> > it
>>>>>> > > wouldnt help I think.
>>>>>> > >
>>>>>> > > Le ven. 30 nov. 2018 06:21, John D. Ament 
>>>>>> a
>>>>>> > écrit
>>>>>> > > :
>>>>>> > >
>>>>>> > > > The question posed to the MP team does not really match the
>>>>>> question
>>>>>> > > > posted here, and seems to be a tangental ask.
>>>>>> > > >
>>>>>> > > > The problem is this line of code [1], and nothing to do with
>>>>>> TomEE's
>>>>>> > > > behavior; it defaults to JSON even though the spec states it
>>>>>> should be
>>>>>> > > > YAML.  Perhaps a clean solution would be to make this a config
>>>>>> setting?
>>>>>> > > > But seems like there's a missing TCK test as well.  I'd also
>>>>>> question
>>>>>> > > when
>>>>>> > > > a browser goes here, what does it send in the Accepts header.
>>>>>> My guess
>>>>>> > > is
>>>>>> > > > most modern browsers send text/html which also wouldn't line up.
>>>>>> > > >
>>>>>> > > > John
>>>>>> > > >
>>>>>> > > > [1]:
>>>>>> > > >
>>>>>> > >
>>>>>> >
>>>>>> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
>>>>>> > > >
>>>>>> > > > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
>>>>>> > > rmannibu...@gmail.com>
>>>>>> > > > wrote:
>>>>>> > > >
>>>>>> > > >> Response is fine (thanks jaxrs), request is up to jaxrs
>>>>>> runtime so
>>>>>> > > >> depends where you deploy it (i dont think implementing a
>>>>>> custom writer
>>>>>> > > for
>>>>>> > > >> that is right for users, it has too much pitfalls once
>>>>>> integrated to
>>>>>> > > >> anything else than this very specific spec).
>>>>>> > > >>
>>>>>> > > >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
>>>>>> > > >> jonathan.gallim...@gmail.com> a écrit :
>>>>>> > > >>
>>>>>> > > >>> If the spec requires that, then I'd expect to get a YAML
>>>>>> response if
>>>>>> > > >>> making a request without an `Accept` header on the request.
>>>>>> > > >>>
>>>>>> > > >>> I haven't looked through the microprofile-openapi TCK, but
>>>>>> I'd expect
>>>>>> > > >>> that to be tested, and I'd suggest contributing a test there
>>>>>> if there
>>>>>> > > isn't
>>>>>> > > >>> one.
>>>>>> > > >>>
>>>>>> > > >>> If you wanted to explicitly request a YAML response, I'd
>>>>>> expect one
>>>>>> > of
>>>>>> > > >>> these to work:
>>>>>> > > >>>
>>>>>> > > >>> Accept: application/x-yaml
>>>>>> > > >>> Accept: text/yaml
>>>>>> > > >>>
>>>>>> > > >>> I'd expect a Content-Type header on the response to identify
>>>>>> the mime
>>>>>> > > >>> type of the response, whatever is being returned.
>>>>>> > > >>>
>>>>>> > > >>> Jon
>>>>>> > > >>>
>>>>>> > > >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
>>>>>> > > >>> ivanjunc...@gmail.com> wrote:
>>>>>> > > >>>
>>>>>> > > >>>> Hey guys, I think I found a bug in OpenAPI implementation.
>>>>>> > > >>>>
>>>>>> > > >>>> The spec says:
>>>>>> > > >>>> "The default format of the /openapi endpoint is YAML."
>>>>>> > > >>>>
>>>>>> > > >>>> But when I try to access /openapi it returns JSON by default.
>>>>>> > > >>>>
>>>>>> > > >>>> This is not correct.
>>>>>> > > >>>>
>>>>>> > > >>>> Also how can I access yaml if it is not default?
>>>>>> > > >>>>
>>>>>> > > >>>
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Atentamente:
>>>>>> César Hernández Mendoza.
>>>>>>
>>>>>

Re: Microprofile OpenAPI

[Ivan Junckes Filho]

gt; > least).
>>>>> > >
>>>>> > > So yes we can make this value confifurable but this never happens.
>>>>> Ivan's
>>>>> > > case was even with cxf client which sets a value normally by
>>>>> default so
>>>>> > it
>>>>> > > wouldnt help I think.
>>>>> > >
>>>>> > > Le ven. 30 nov. 2018 06:21, John D. Ament 
>>>>> a
>>>>> > écrit
>>>>> > > :
>>>>> > >
>>>>> > > > The question posed to the MP team does not really match the
>>>>> question
>>>>> > > > posted here, and seems to be a tangental ask.
>>>>> > > >
>>>>> > > > The problem is this line of code [1], and nothing to do with
>>>>> TomEE's
>>>>> > > > behavior; it defaults to JSON even though the spec states it
>>>>> should be
>>>>> > > > YAML.  Perhaps a clean solution would be to make this a config
>>>>> setting?
>>>>> > > > But seems like there's a missing TCK test as well.  I'd also
>>>>> question
>>>>> > > when
>>>>> > > > a browser goes here, what does it send in the Accepts header.
>>>>> My guess
>>>>> > > is
>>>>> > > > most modern browsers send text/html which also wouldn't line up.
>>>>> > > >
>>>>> > > > John
>>>>> > > >
>>>>> > > > [1]:
>>>>> > > >
>>>>> > >
>>>>> >
>>>>> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
>>>>> > > >
>>>>> > > > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
>>>>> > > rmannibu...@gmail.com>
>>>>> > > > wrote:
>>>>> > > >
>>>>> > > >> Response is fine (thanks jaxrs), request is up to jaxrs runtime
>>>>> so
>>>>> > > >> depends where you deploy it (i dont think implementing a custom
>>>>> writer
>>>>> > > for
>>>>> > > >> that is right for users, it has too much pitfalls once
>>>>> integrated to
>>>>> > > >> anything else than this very specific spec).
>>>>> > > >>
>>>>> > > >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
>>>>> > > >> jonathan.gallim...@gmail.com> a écrit :
>>>>> > > >>
>>>>> > > >>> If the spec requires that, then I'd expect to get a YAML
>>>>> response if
>>>>> > > >>> making a request without an `Accept` header on the request.
>>>>> > > >>>
>>>>> > > >>> I haven't looked through the microprofile-openapi TCK, but I'd
>>>>> expect
>>>>> > > >>> that to be tested, and I'd suggest contributing a test there
>>>>> if there
>>>>> > > isn't
>>>>> > > >>> one.
>>>>> > > >>>
>>>>> > > >>> If you wanted to explicitly request a YAML response, I'd
>>>>> expect one
>>>>> > of
>>>>> > > >>> these to work:
>>>>> > > >>>
>>>>> > > >>> Accept: application/x-yaml
>>>>> > > >>> Accept: text/yaml
>>>>> > > >>>
>>>>> > > >>> I'd expect a Content-Type header on the response to identify
>>>>> the mime
>>>>> > > >>> type of the response, whatever is being returned.
>>>>> > > >>>
>>>>> > > >>> Jon
>>>>> > > >>>
>>>>> > > >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
>>>>> > > >>> ivanjunc...@gmail.com> wrote:
>>>>> > > >>>
>>>>> > > >>>> Hey guys, I think I found a bug in OpenAPI implementation.
>>>>> > > >>>>
>>>>> > > >>>> The spec says:
>>>>> > > >>>> "The default format of the /openapi endpoint is YAML."
>>>>> > > >>>>
>>>>> > > >>>> But when I try to access /openapi it returns JSON by default.
>>>>> > > >>>>
>>>>> > > >>>> This is not correct.
>>>>> > > >>>>
>>>>> > > >>>> Also how can I access yaml if it is not default?
>>>>> > > >>>>
>>>>> > > >>>
>>>>> > >
>>>>> >
>>>>>
>>>>>
>>>>> --
>>>>> Atentamente:
>>>>> César Hernández Mendoza.
>>>>>
>>>>

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

I don't understand why you say so Ivan, it is perfectly compatible.

Also to answer clearly to your question: I prefer to have an impl not
compatible with the spec when the spec says something stupid, most of the
time we put toggle to be able to be compatible but sometimes there is not
even a way to be compatible, this is what has been done in TomEE since
years and it works well making users happy rather than spec leads.

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 ven. 30 nov. 2018 à 17:11, Ivan Junckes Filho  a
écrit :

> This is against the spec as well, yaml is required and must always be
> default. Do we really want to let our implementation not compatible with
> that?
>
> On Fri, Nov 30, 2018 at 2:03 PM Romain Manni-Bucau 
> wrote:
>
>> If jackson yaml is present it will add a (jackson) writer for yaml, if
>> not it stays on json.
>>
>> 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 ven. 30 nov. 2018 à 16:51, Ivan Junckes Filho 
>> a écrit :
>>
>>> @Romain Manni-Bucau  not sure I understood you.
>>> Are you saying you will work to make it compatible with the spec? Have yaml
>>> as default?
>>>
>>> On Fri, Nov 30, 2018 at 1:30 PM César Hernández Mendoza <
>>> cesargu...@gmail.com> wrote:
>>>
>>>> >
>>>> > I think regardless of what the MicroProfile team decides, we need to
>>>> make
>>>> > it work as the specification says. Then iterate from there.
>>>> > In my opinion this is a big problem that makes us strongly
>>>> incompatible
>>>> > with the standard.
>>>>
>>>>
>>>> +1
>>>>
>>>> El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<
>>>> ivanjunc...@gmail.com>)
>>>> escribió:
>>>>
>>>> > I think regardless of what the MicroProfile team decides, we need to
>>>> make
>>>> > it work as the specification says. Then iterate from there.
>>>> >
>>>> > In my opinion this is a big problem that makes us strongly
>>>> incompatible
>>>> > with the standard.
>>>> >
>>>> > On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <
>>>> rmannibu...@gmail.com>
>>>> > wrote:
>>>> >
>>>> > > Browser and all clients default to */* or octect/stream so the else
>>>> is
>>>> > > never used normally and was here just to put a mimetype from an
>>>> optional.
>>>> > >
>>>> > > Browsers even send a kind of "all you can" value (*/*, html, xml at
>>>> > least).
>>>> > >
>>>> > > So yes we can make this value confifurable but this never happens.
>>>> Ivan's
>>>> > > case was even with cxf client which sets a value normally by
>>>> default so
>>>> > it
>>>> > > wouldnt help I think.
>>>> > >
>>>> > > Le ven. 30 nov. 2018 06:21, John D. Ament  a
>>>> > écrit
>>>> > > :
>>>> > >
>>>> > > > The question posed to the MP team does not really match the
>>>> question
>>>> > > > posted here, and seems to be a tangental ask.
>>>> > > >
>>>> > > > The problem is this line of code [1], and nothing to do with
>>>> TomEE's
>>>> > > > behavior; it defaults to JSON even though the spec states it
>>>> should be
>>>> > > > YAML.  Perhaps a clean solution would be to make this a config
>>>> setting?
>>>> > > > But seems like there's a missing TCK test as well.  I'd also
>>>> question
>>>> > > when
>>>> > > > a browser goes here, what does it send in the Accepts hea

Re: Microprofile OpenAPI

[Ivan Junckes Filho]

This is against the spec as well, yaml is required and must always be
default. Do we really want to let our implementation not compatible with
that?

On Fri, Nov 30, 2018 at 2:03 PM Romain Manni-Bucau 
wrote:

> If jackson yaml is present it will add a (jackson) writer for yaml, if not
> it stays on json.
>
> 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 ven. 30 nov. 2018 à 16:51, Ivan Junckes Filho 
> a écrit :
>
>> @Romain Manni-Bucau  not sure I understood you.
>> Are you saying you will work to make it compatible with the spec? Have yaml
>> as default?
>>
>> On Fri, Nov 30, 2018 at 1:30 PM César Hernández Mendoza <
>> cesargu...@gmail.com> wrote:
>>
>>> >
>>> > I think regardless of what the MicroProfile team decides, we need to
>>> make
>>> > it work as the specification says. Then iterate from there.
>>> > In my opinion this is a big problem that makes us strongly incompatible
>>> > with the standard.
>>>
>>>
>>> +1
>>>
>>> El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<
>>> ivanjunc...@gmail.com>)
>>> escribió:
>>>
>>> > I think regardless of what the MicroProfile team decides, we need to
>>> make
>>> > it work as the specification says. Then iterate from there.
>>> >
>>> > In my opinion this is a big problem that makes us strongly incompatible
>>> > with the standard.
>>> >
>>> > On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <
>>> rmannibu...@gmail.com>
>>> > wrote:
>>> >
>>> > > Browser and all clients default to */* or octect/stream so the else
>>> is
>>> > > never used normally and was here just to put a mimetype from an
>>> optional.
>>> > >
>>> > > Browsers even send a kind of "all you can" value (*/*, html, xml at
>>> > least).
>>> > >
>>> > > So yes we can make this value confifurable but this never happens.
>>> Ivan's
>>> > > case was even with cxf client which sets a value normally by default
>>> so
>>> > it
>>> > > wouldnt help I think.
>>> > >
>>> > > Le ven. 30 nov. 2018 06:21, John D. Ament  a
>>> > écrit
>>> > > :
>>> > >
>>> > > > The question posed to the MP team does not really match the
>>> question
>>> > > > posted here, and seems to be a tangental ask.
>>> > > >
>>> > > > The problem is this line of code [1], and nothing to do with
>>> TomEE's
>>> > > > behavior; it defaults to JSON even though the spec states it
>>> should be
>>> > > > YAML.  Perhaps a clean solution would be to make this a config
>>> setting?
>>> > > > But seems like there's a missing TCK test as well.  I'd also
>>> question
>>> > > when
>>> > > > a browser goes here, what does it send in the Accepts header.  My
>>> guess
>>> > > is
>>> > > > most modern browsers send text/html which also wouldn't line up.
>>> > > >
>>> > > > John
>>> > > >
>>> > > > [1]:
>>> > > >
>>> > >
>>> >
>>> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
>>> > > >
>>> > > > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
>>> > > rmannibu...@gmail.com>
>>> > > > wrote:
>>> > > >
>>> > > >> Response is fine (thanks jaxrs), request is up to jaxrs runtime so
>>> > > >> depends where you deploy it (i dont think implementing a custom
>>> writer
>>> > > for
>>> > > >> that is right for users, it has too much pitfalls once integrated
>>> to
>>> > > >> anything else than this very specific spec).
>>> > > >>
>>> > &g

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

If jackson yaml is present it will add a (jackson) writer for yaml, if not
it stays on json.

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 ven. 30 nov. 2018 à 16:51, Ivan Junckes Filho  a
écrit :

> @Romain Manni-Bucau  not sure I understood you.
> Are you saying you will work to make it compatible with the spec? Have yaml
> as default?
>
> On Fri, Nov 30, 2018 at 1:30 PM César Hernández Mendoza <
> cesargu...@gmail.com> wrote:
>
>> >
>> > I think regardless of what the MicroProfile team decides, we need to
>> make
>> > it work as the specification says. Then iterate from there.
>> > In my opinion this is a big problem that makes us strongly incompatible
>> > with the standard.
>>
>>
>> +1
>>
>> El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<
>> ivanjunc...@gmail.com>)
>> escribió:
>>
>> > I think regardless of what the MicroProfile team decides, we need to
>> make
>> > it work as the specification says. Then iterate from there.
>> >
>> > In my opinion this is a big problem that makes us strongly incompatible
>> > with the standard.
>> >
>> > On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> > wrote:
>> >
>> > > Browser and all clients default to */* or octect/stream so the else is
>> > > never used normally and was here just to put a mimetype from an
>> optional.
>> > >
>> > > Browsers even send a kind of "all you can" value (*/*, html, xml at
>> > least).
>> > >
>> > > So yes we can make this value confifurable but this never happens.
>> Ivan's
>> > > case was even with cxf client which sets a value normally by default
>> so
>> > it
>> > > wouldnt help I think.
>> > >
>> > > Le ven. 30 nov. 2018 06:21, John D. Ament  a
>> > écrit
>> > > :
>> > >
>> > > > The question posed to the MP team does not really match the question
>> > > > posted here, and seems to be a tangental ask.
>> > > >
>> > > > The problem is this line of code [1], and nothing to do with TomEE's
>> > > > behavior; it defaults to JSON even though the spec states it should
>> be
>> > > > YAML.  Perhaps a clean solution would be to make this a config
>> setting?
>> > > > But seems like there's a missing TCK test as well.  I'd also
>> question
>> > > when
>> > > > a browser goes here, what does it send in the Accepts header.  My
>> guess
>> > > is
>> > > > most modern browsers send text/html which also wouldn't line up.
>> > > >
>> > > > John
>> > > >
>> > > > [1]:
>> > > >
>> > >
>> >
>> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
>> > > >
>> > > > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
>> > > rmannibu...@gmail.com>
>> > > > wrote:
>> > > >
>> > > >> Response is fine (thanks jaxrs), request is up to jaxrs runtime so
>> > > >> depends where you deploy it (i dont think implementing a custom
>> writer
>> > > for
>> > > >> that is right for users, it has too much pitfalls once integrated
>> to
>> > > >> anything else than this very specific spec).
>> > > >>
>> > > >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
>> > > >> jonathan.gallim...@gmail.com> a écrit :
>> > > >>
>> > > >>> If the spec requires that, then I'd expect to get a YAML response
>> if
>> > > >>> making a request without an `Accept` header on the request.
>> > > >>>
>> > > >>> I haven't looked through the microprofile-openapi TCK, but I'd
>> expect
>> > > >>> that to be tested, and I'd suggest contributing a test there if
>> there
>> > > isn't
>> > > >>> one.
>> > > >>>
>> > > >>> If you wanted to explicitly request a YAML response, I'd expect
>> one
>> > of
>> > > >>> these to work:
>> > > >>>
>> > > >>> Accept: application/x-yaml
>> > > >>> Accept: text/yaml
>> > > >>>
>> > > >>> I'd expect a Content-Type header on the response to identify the
>> mime
>> > > >>> type of the response, whatever is being returned.
>> > > >>>
>> > > >>> Jon
>> > > >>>
>> > > >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
>> > > >>> ivanjunc...@gmail.com> wrote:
>> > > >>>
>> > > >>>> Hey guys, I think I found a bug in OpenAPI implementation.
>> > > >>>>
>> > > >>>> The spec says:
>> > > >>>> "The default format of the /openapi endpoint is YAML."
>> > > >>>>
>> > > >>>> But when I try to access /openapi it returns JSON by default.
>> > > >>>>
>> > > >>>> This is not correct.
>> > > >>>>
>> > > >>>> Also how can I access yaml if it is not default?
>> > > >>>>
>> > > >>>
>> > >
>> >
>>
>>
>> --
>> Atentamente:
>> César Hernández Mendoza.
>>
>

Re: Microprofile OpenAPI

[Ivan Junckes Filho]

@Romain Manni-Bucau  not sure I understood you. Are
you saying you will work to make it compatible with the spec? Have yaml as
default?

On Fri, Nov 30, 2018 at 1:30 PM César Hernández Mendoza <
cesargu...@gmail.com> wrote:

> >
> > I think regardless of what the MicroProfile team decides, we need to make
> > it work as the specification says. Then iterate from there.
> > In my opinion this is a big problem that makes us strongly incompatible
> > with the standard.
>
>
> +1
>
> El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<
> ivanjunc...@gmail.com>)
> escribió:
>
> > I think regardless of what the MicroProfile team decides, we need to make
> > it work as the specification says. Then iterate from there.
> >
> > In my opinion this is a big problem that makes us strongly incompatible
> > with the standard.
> >
> > On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Browser and all clients default to */* or octect/stream so the else is
> > > never used normally and was here just to put a mimetype from an
> optional.
> > >
> > > Browsers even send a kind of "all you can" value (*/*, html, xml at
> > least).
> > >
> > > So yes we can make this value confifurable but this never happens.
> Ivan's
> > > case was even with cxf client which sets a value normally by default so
> > it
> > > wouldnt help I think.
> > >
> > > Le ven. 30 nov. 2018 06:21, John D. Ament  a
> > écrit
> > > :
> > >
> > > > The question posed to the MP team does not really match the question
> > > > posted here, and seems to be a tangental ask.
> > > >
> > > > The problem is this line of code [1], and nothing to do with TomEE's
> > > > behavior; it defaults to JSON even though the spec states it should
> be
> > > > YAML.  Perhaps a clean solution would be to make this a config
> setting?
> > > > But seems like there's a missing TCK test as well.  I'd also question
> > > when
> > > > a browser goes here, what does it send in the Accepts header.  My
> guess
> > > is
> > > > most modern browsers send text/html which also wouldn't line up.
> > > >
> > > > John
> > > >
> > > > [1]:
> > > >
> > >
> >
> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
> > > >
> > > > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > >> Response is fine (thanks jaxrs), request is up to jaxrs runtime so
> > > >> depends where you deploy it (i dont think implementing a custom
> writer
> > > for
> > > >> that is right for users, it has too much pitfalls once integrated to
> > > >> anything else than this very specific spec).
> > > >>
> > > >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
> > > >> jonathan.gallim...@gmail.com> a écrit :
> > > >>
> > > >>> If the spec requires that, then I'd expect to get a YAML response
> if
> > > >>> making a request without an `Accept` header on the request.
> > > >>>
> > > >>> I haven't looked through the microprofile-openapi TCK, but I'd
> expect
> > > >>> that to be tested, and I'd suggest contributing a test there if
> there
> > > isn't
> > > >>> one.
> > > >>>
> > > >>> If you wanted to explicitly request a YAML response, I'd expect one
> > of
> > > >>> these to work:
> > > >>>
> > > >>> Accept: application/x-yaml
> > > >>> Accept: text/yaml
> > > >>>
> > > >>> I'd expect a Content-Type header on the response to identify the
> mime
> > > >>> type of the response, whatever is being returned.
> > > >>>
> > > >>> Jon
> > > >>>
> > > >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
> > > >>> ivanjunc...@gmail.com> wrote:
> > > >>>
> > > >>>> Hey guys, I think I found a bug in OpenAPI implementation.
> > > >>>>
> > > >>>> The spec says:
> > > >>>> "The default format of the /openapi endpoint is YAML."
> > > >>>>
> > > >>>> But when I try to access /openapi it returns JSON by default.
> > > >>>>
> > > >>>> This is not correct.
> > > >>>>
> > > >>>> Also how can I access yaml if it is not default?
> > > >>>>
> > > >>>
> > >
> >
>
>
> --
> Atentamente:
> César Hernández Mendoza.
>

Re: Microprofile OpenAPI

[César Hernández Mendoza]

>
> I think regardless of what the MicroProfile team decides, we need to make
> it work as the specification says. Then iterate from there.
> In my opinion this is a big problem that makes us strongly incompatible
> with the standard.


+1

El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho ()
escribió:

> I think regardless of what the MicroProfile team decides, we need to make
> it work as the specification says. Then iterate from there.
>
> In my opinion this is a big problem that makes us strongly incompatible
> with the standard.
>
> On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau 
> wrote:
>
> > Browser and all clients default to */* or octect/stream so the else is
> > never used normally and was here just to put a mimetype from an optional.
> >
> > Browsers even send a kind of "all you can" value (*/*, html, xml at
> least).
> >
> > So yes we can make this value confifurable but this never happens. Ivan's
> > case was even with cxf client which sets a value normally by default so
> it
> > wouldnt help I think.
> >
> > Le ven. 30 nov. 2018 06:21, John D. Ament  a
> écrit
> > :
> >
> > > The question posed to the MP team does not really match the question
> > > posted here, and seems to be a tangental ask.
> > >
> > > The problem is this line of code [1], and nothing to do with TomEE's
> > > behavior; it defaults to JSON even though the spec states it should be
> > > YAML.  Perhaps a clean solution would be to make this a config setting?
> > > But seems like there's a missing TCK test as well.  I'd also question
> > when
> > > a browser goes here, what does it send in the Accepts header.  My guess
> > is
> > > most modern browsers send text/html which also wouldn't line up.
> > >
> > > John
> > >
> > > [1]:
> > >
> >
> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
> > >
> > > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > >> Response is fine (thanks jaxrs), request is up to jaxrs runtime so
> > >> depends where you deploy it (i dont think implementing a custom writer
> > for
> > >> that is right for users, it has too much pitfalls once integrated to
> > >> anything else than this very specific spec).
> > >>
> > >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
> > >> jonathan.gallim...@gmail.com> a écrit :
> > >>
> > >>> If the spec requires that, then I'd expect to get a YAML response if
> > >>> making a request without an `Accept` header on the request.
> > >>>
> > >>> I haven't looked through the microprofile-openapi TCK, but I'd expect
> > >>> that to be tested, and I'd suggest contributing a test there if there
> > isn't
> > >>> one.
> > >>>
> > >>> If you wanted to explicitly request a YAML response, I'd expect one
> of
> > >>> these to work:
> > >>>
> > >>> Accept: application/x-yaml
> > >>> Accept: text/yaml
> > >>>
> > >>> I'd expect a Content-Type header on the response to identify the mime
> > >>> type of the response, whatever is being returned.
> > >>>
> > >>> Jon
> > >>>
> > >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
> > >>> ivanjunc...@gmail.com> wrote:
> > >>>
> > >>>> Hey guys, I think I found a bug in OpenAPI implementation.
> > >>>>
> > >>>> The spec says:
> > >>>> "The default format of the /openapi endpoint is YAML."
> > >>>>
> > >>>> But when I try to access /openapi it returns JSON by default.
> > >>>>
> > >>>> This is not correct.
> > >>>>
> > >>>> Also how can I access yaml if it is not default?
> > >>>>
> > >>>
> >
>


-- 
Atentamente:
César Hernández Mendoza.

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

I'll add */* for yaml endpoint to complement text/plain, this will solve
the ambiguity

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 ven. 30 nov. 2018 à 12:44, Ivan Junckes Filho  a
écrit :

> I think regardless of what the MicroProfile team decides, we need to make
> it work as the specification says. Then iterate from there.
>
> In my opinion this is a big problem that makes us strongly incompatible
> with the standard.
>
> On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau 
> wrote:
>
>> Browser and all clients default to */* or octect/stream so the else is
>> never used normally and was here just to put a mimetype from an optional.
>>
>> Browsers even send a kind of "all you can" value (*/*, html, xml at
>> least).
>>
>> So yes we can make this value confifurable but this never happens. Ivan's
>> case was even with cxf client which sets a value normally by default so it
>> wouldnt help I think.
>>
>> Le ven. 30 nov. 2018 06:21, John D. Ament  a
>> écrit :
>>
>> > The question posed to the MP team does not really match the question
>> > posted here, and seems to be a tangental ask.
>> >
>> > The problem is this line of code [1], and nothing to do with TomEE's
>> > behavior; it defaults to JSON even though the spec states it should be
>> > YAML.  Perhaps a clean solution would be to make this a config setting?
>> > But seems like there's a missing TCK test as well.  I'd also question
>> when
>> > a browser goes here, what does it send in the Accepts header.  My guess
>> is
>> > most modern browsers send text/html which also wouldn't line up.
>> >
>> > John
>> >
>> > [1]:
>> >
>> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
>> >
>> > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> > wrote:
>> >
>> >> Response is fine (thanks jaxrs), request is up to jaxrs runtime so
>> >> depends where you deploy it (i dont think implementing a custom writer
>> for
>> >> that is right for users, it has too much pitfalls once integrated to
>> >> anything else than this very specific spec).
>> >>
>> >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
>> >> jonathan.gallim...@gmail.com> a écrit :
>> >>
>> >>> If the spec requires that, then I'd expect to get a YAML response if
>> >>> making a request without an `Accept` header on the request.
>> >>>
>> >>> I haven't looked through the microprofile-openapi TCK, but I'd expect
>> >>> that to be tested, and I'd suggest contributing a test there if there
>> isn't
>> >>> one.
>> >>>
>> >>> If you wanted to explicitly request a YAML response, I'd expect one of
>> >>> these to work:
>> >>>
>> >>> Accept: application/x-yaml
>> >>> Accept: text/yaml
>> >>>
>> >>> I'd expect a Content-Type header on the response to identify the mime
>> >>> type of the response, whatever is being returned.
>> >>>
>> >>> Jon
>> >>>
>> >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
>> >>> ivanjunc...@gmail.com> wrote:
>> >>>
>> >>>> Hey guys, I think I found a bug in OpenAPI implementation.
>> >>>>
>> >>>> The spec says:
>> >>>> "The default format of the /openapi endpoint is YAML."
>> >>>>
>> >>>> But when I try to access /openapi it returns JSON by default.
>> >>>>
>> >>>> This is not correct.
>> >>>>
>> >>>> Also how can I access yaml if it is not default?
>> >>>>
>> >>>
>>
>

Re: Microprofile OpenAPI

[Ivan Junckes Filho]

I think regardless of what the MicroProfile team decides, we need to make
it work as the specification says. Then iterate from there.

In my opinion this is a big problem that makes us strongly incompatible
with the standard.

On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau 
wrote:

> Browser and all clients default to */* or octect/stream so the else is
> never used normally and was here just to put a mimetype from an optional.
>
> Browsers even send a kind of "all you can" value (*/*, html, xml at least).
>
> So yes we can make this value confifurable but this never happens. Ivan's
> case was even with cxf client which sets a value normally by default so it
> wouldnt help I think.
>
> Le ven. 30 nov. 2018 06:21, John D. Ament  a écrit
> :
>
> > The question posed to the MP team does not really match the question
> > posted here, and seems to be a tangental ask.
> >
> > The problem is this line of code [1], and nothing to do with TomEE's
> > behavior; it defaults to JSON even though the spec states it should be
> > YAML.  Perhaps a clean solution would be to make this a config setting?
> > But seems like there's a missing TCK test as well.  I'd also question
> when
> > a browser goes here, what does it send in the Accepts header.  My guess
> is
> > most modern browsers send text/html which also wouldn't line up.
> >
> > John
> >
> > [1]:
> >
> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
> >
> > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> Response is fine (thanks jaxrs), request is up to jaxrs runtime so
> >> depends where you deploy it (i dont think implementing a custom writer
> for
> >> that is right for users, it has too much pitfalls once integrated to
> >> anything else than this very specific spec).
> >>
> >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
> >> jonathan.gallim...@gmail.com> a écrit :
> >>
> >>> If the spec requires that, then I'd expect to get a YAML response if
> >>> making a request without an `Accept` header on the request.
> >>>
> >>> I haven't looked through the microprofile-openapi TCK, but I'd expect
> >>> that to be tested, and I'd suggest contributing a test there if there
> isn't
> >>> one.
> >>>
> >>> If you wanted to explicitly request a YAML response, I'd expect one of
> >>> these to work:
> >>>
> >>> Accept: application/x-yaml
> >>> Accept: text/yaml
> >>>
> >>> I'd expect a Content-Type header on the response to identify the mime
> >>> type of the response, whatever is being returned.
> >>>
> >>> Jon
> >>>
> >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
> >>> ivanjunc...@gmail.com> wrote:
> >>>
> >>>> Hey guys, I think I found a bug in OpenAPI implementation.
> >>>>
> >>>> The spec says:
> >>>> "The default format of the /openapi endpoint is YAML."
> >>>>
> >>>> But when I try to access /openapi it returns JSON by default.
> >>>>
> >>>> This is not correct.
> >>>>
> >>>> Also how can I access yaml if it is not default?
> >>>>
> >>>
>

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

Browser and all clients default to */* or octect/stream so the else is
never used normally and was here just to put a mimetype from an optional.

Browsers even send a kind of "all you can" value (*/*, html, xml at least).

So yes we can make this value confifurable but this never happens. Ivan's
case was even with cxf client which sets a value normally by default so it
wouldnt help I think.

Le ven. 30 nov. 2018 06:21, John D. Ament  a écrit :

> The question posed to the MP team does not really match the question
> posted here, and seems to be a tangental ask.
>
> The problem is this line of code [1], and nothing to do with TomEE's
> behavior; it defaults to JSON even though the spec states it should be
> YAML.  Perhaps a clean solution would be to make this a config setting?
> But seems like there's a missing TCK test as well.  I'd also question when
> a browser goes here, what does it send in the Accepts header.  My guess is
> most modern browsers send text/html which also wouldn't line up.
>
> John
>
> [1]:
> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
>
> On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau 
> wrote:
>
>> Response is fine (thanks jaxrs), request is up to jaxrs runtime so
>> depends where you deploy it (i dont think implementing a custom writer for
>> that is right for users, it has too much pitfalls once integrated to
>> anything else than this very specific spec).
>>
>> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> a écrit :
>>
>>> If the spec requires that, then I'd expect to get a YAML response if
>>> making a request without an `Accept` header on the request.
>>>
>>> I haven't looked through the microprofile-openapi TCK, but I'd expect
>>> that to be tested, and I'd suggest contributing a test there if there isn't
>>> one.
>>>
>>> If you wanted to explicitly request a YAML response, I'd expect one of
>>> these to work:
>>>
>>> Accept: application/x-yaml
>>> Accept: text/yaml
>>>
>>> I'd expect a Content-Type header on the response to identify the mime
>>> type of the response, whatever is being returned.
>>>
>>> Jon
>>>
>>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
>>> ivanjunc...@gmail.com> wrote:
>>>
>>>> Hey guys, I think I found a bug in OpenAPI implementation.
>>>>
>>>> The spec says:
>>>> "The default format of the /openapi endpoint is YAML."
>>>>
>>>> But when I try to access /openapi it returns JSON by default.
>>>>
>>>> This is not correct.
>>>>
>>>> Also how can I access yaml if it is not default?
>>>>
>>>

Re: Microprofile OpenAPI

[John D. Ament]

The question posed to the MP team does not really match the question posted
here, and seems to be a tangental ask.

The problem is this line of code [1], and nothing to do with TomEE's
behavior; it defaults to JSON even though the spec states it should be
YAML.  Perhaps a clean solution would be to make this a config setting?
But seems like there's a missing TCK test as well.  I'd also question when
a browser goes here, what does it send in the Accepts header.  My guess is
most modern browsers send text/html which also wouldn't line up.

John

[1]:
https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57

On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau 
wrote:

> Response is fine (thanks jaxrs), request is up to jaxrs runtime so depends
> where you deploy it (i dont think implementing a custom writer for that is
> right for users, it has too much pitfalls once integrated to anything else
> than this very specific spec).
>
> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> a écrit :
>
>> If the spec requires that, then I'd expect to get a YAML response if
>> making a request without an `Accept` header on the request.
>>
>> I haven't looked through the microprofile-openapi TCK, but I'd expect
>> that to be tested, and I'd suggest contributing a test there if there isn't
>> one.
>>
>> If you wanted to explicitly request a YAML response, I'd expect one of
>> these to work:
>>
>> Accept: application/x-yaml
>> Accept: text/yaml
>>
>> I'd expect a Content-Type header on the response to identify the mime
>> type of the response, whatever is being returned.
>>
>> Jon
>>
>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho 
>> wrote:
>>
>>> Hey guys, I think I found a bug in OpenAPI implementation.
>>>
>>> The spec says:
>>> "The default format of the /openapi endpoint is YAML."
>>>
>>> But when I try to access /openapi it returns JSON by default.
>>>
>>> This is not correct.
>>>
>>> Also how can I access yaml if it is not default?
>>>
>>

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

Response is fine (thanks jaxrs), request is up to jaxrs runtime so depends
where you deploy it (i dont think implementing a custom writer for that is
right for users, it has too much pitfalls once integrated to anything else
than this very specific spec).

Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore 
a écrit :

> If the spec requires that, then I'd expect to get a YAML response if
> making a request without an `Accept` header on the request.
>
> I haven't looked through the microprofile-openapi TCK, but I'd expect that
> to be tested, and I'd suggest contributing a test there if there isn't one.
>
> If you wanted to explicitly request a YAML response, I'd expect one of
> these to work:
>
> Accept: application/x-yaml
> Accept: text/yaml
>
> I'd expect a Content-Type header on the response to identify the mime type
> of the response, whatever is being returned.
>
> Jon
>
> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho 
> wrote:
>
>> Hey guys, I think I found a bug in OpenAPI implementation.
>>
>> The spec says:
>> "The default format of the /openapi endpoint is YAML."
>>
>> But when I try to access /openapi it returns JSON by default.
>>
>> This is not correct.
>>
>> Also how can I access yaml if it is not default?
>>
>

Re: Microprofile OpenAPI

[Jonathan Gallimore]

If the spec requires that, then I'd expect to get a YAML response if making
a request without an `Accept` header on the request.

I haven't looked through the microprofile-openapi TCK, but I'd expect that
to be tested, and I'd suggest contributing a test there if there isn't one.

If you wanted to explicitly request a YAML response, I'd expect one of
these to work:

Accept: application/x-yaml
Accept: text/yaml

I'd expect a Content-Type header on the response to identify the mime type
of the response, whatever is being returned.

Jon

On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho 
wrote:

> Hey guys, I think I found a bug in OpenAPI implementation.
>
> The spec says:
> "The default format of the /openapi endpoint is YAML."
>
> But when I try to access /openapi it returns JSON by default.
>
> This is not correct.
>
> Also how can I access yaml if it is not default?
>

Re: Microprofile OpenAPI

[Richard Monson-Haefel]

True. It also doesn't mean that you not wrong. ;-)

On Thu, Nov 29, 2018 at 2:04 PM Romain Manni-Bucau 
wrote:

> Does not mean im not right ;)
>
> Le jeu. 29 nov. 2018 20:33, Richard Monson-Haefel 
> a écrit :
>
> > Ivan is right. The default for MicroProfile is yaml. It would only be
> > json if the accept heard specifies json.  Here is the exact wording from
> > section 5.2
> >
> > "The default format of the /openapi endpoint is YAML.
> >
> > Vendors must also support the JSON format if the request contains an
> Accept
> > header with a value of application/json, in which case the response must
> > contain a Content-Type header with a value of application/json."
> >
> > On Thu, Nov 29, 2018 at 11:03 AM Ivan Junckes Filho <
> ivanjunc...@gmail.com
> > >
> > wrote:
> >
> > > Hey Romain, take a look on:
> > >
> > >
> > >
> >
> https://download.eclipse.org/microprofile/microprofile-open-api-1.0/microprofile-openapi-spec.html#_content_format
> > >
> > > It is clear for me there, that the default should be yaml.
> > >
> > > On Thu, Nov 29, 2018 at 2:58 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Hello Ivan,
> > > >
> > > > this is actually not exactly the case, the impl is writer agnostic
> and
> > > > fully relies on JAXRS for that so if you have a body writer which
> > matches
> > > > OpenAPI and returns yaml by default or
> > > > which prefer yaml over json then you will have the behavior you
> > describe.
> > > >
> > > > To get yaml you can send the Accept header valued with yaml media
> type
> > > > like "text/yaml" for some implementations.
> > > >
> > > > Side note: the impl does not impose any body writer to be integrable
> in
> > > > any environment and does not enforce yaml as well cause it is not
> part
> > of
> > > > the core of microprofile (and hopefully will never be) so no reason
> to
> > > > import a lib (which can be heavy and potentially with
> vulnerabilities +
> > > > work for the users to maintain it) for that.
> > > >
> > > > 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. 29 nov. 2018 à 17:50, Ivan Junckes Filho <
> > ivanjunc...@gmail.com>
> > > > a écrit :
> > > >
> > > >> Hey guys, I think I found a bug in OpenAPI implementation.
> > > >>
> > > >> The spec says:
> > > >> "The default format of the /openapi endpoint is YAML."
> > > >>
> > > >> But when I try to access /openapi it returns JSON by default.
> > > >>
> > > >> This is not correct.
> > > >>
> > > >> Also how can I access yaml if it is not default?
> > > >>
> > > >
> > >
> >
> >
> > --
> > Richard Monson-Haefel
> > https://twitter.com/rmonson
> > https://www.linkedin.com/in/monsonhaefel/
> >
>


-- 
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.linkedin.com/in/monsonhaefel/

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

Does not mean im not right ;)

Le jeu. 29 nov. 2018 20:33, Richard Monson-Haefel 
a écrit :

> Ivan is right. The default for MicroProfile is yaml. It would only be
> json if the accept heard specifies json.  Here is the exact wording from
> section 5.2
>
> "The default format of the /openapi endpoint is YAML.
>
> Vendors must also support the JSON format if the request contains an Accept
> header with a value of application/json, in which case the response must
> contain a Content-Type header with a value of application/json."
>
> On Thu, Nov 29, 2018 at 11:03 AM Ivan Junckes Filho  >
> wrote:
>
> > Hey Romain, take a look on:
> >
> >
> >
> https://download.eclipse.org/microprofile/microprofile-open-api-1.0/microprofile-openapi-spec.html#_content_format
> >
> > It is clear for me there, that the default should be yaml.
> >
> > On Thu, Nov 29, 2018 at 2:58 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Hello Ivan,
> > >
> > > this is actually not exactly the case, the impl is writer agnostic and
> > > fully relies on JAXRS for that so if you have a body writer which
> matches
> > > OpenAPI and returns yaml by default or
> > > which prefer yaml over json then you will have the behavior you
> describe.
> > >
> > > To get yaml you can send the Accept header valued with yaml media type
> > > like "text/yaml" for some implementations.
> > >
> > > Side note: the impl does not impose any body writer to be integrable in
> > > any environment and does not enforce yaml as well cause it is not part
> of
> > > the core of microprofile (and hopefully will never be) so no reason to
> > > import a lib (which can be heavy and potentially with vulnerabilities +
> > > work for the users to maintain it) for that.
> > >
> > > 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. 29 nov. 2018 à 17:50, Ivan Junckes Filho <
> ivanjunc...@gmail.com>
> > > a écrit :
> > >
> > >> Hey guys, I think I found a bug in OpenAPI implementation.
> > >>
> > >> The spec says:
> > >> "The default format of the /openapi endpoint is YAML."
> > >>
> > >> But when I try to access /openapi it returns JSON by default.
> > >>
> > >> This is not correct.
> > >>
> > >> Also how can I access yaml if it is not default?
> > >>
> > >
> >
>
>
> --
> Richard Monson-Haefel
> https://twitter.com/rmonson
> https://www.linkedin.com/in/monsonhaefel/
>

Re: Microprofile OpenAPI

[Richard Monson-Haefel]

Ivan is right. The default for MicroProfile is yaml. It would only be
json if the accept heard specifies json.  Here is the exact wording from
section 5.2

"The default format of the /openapi endpoint is YAML.

Vendors must also support the JSON format if the request contains an Accept
header with a value of application/json, in which case the response must
contain a Content-Type header with a value of application/json."

On Thu, Nov 29, 2018 at 11:03 AM Ivan Junckes Filho 
wrote:

> Hey Romain, take a look on:
>
>
> https://download.eclipse.org/microprofile/microprofile-open-api-1.0/microprofile-openapi-spec.html#_content_format
>
> It is clear for me there, that the default should be yaml.
>
> On Thu, Nov 29, 2018 at 2:58 PM Romain Manni-Bucau 
> wrote:
>
> > Hello Ivan,
> >
> > this is actually not exactly the case, the impl is writer agnostic and
> > fully relies on JAXRS for that so if you have a body writer which matches
> > OpenAPI and returns yaml by default or
> > which prefer yaml over json then you will have the behavior you describe.
> >
> > To get yaml you can send the Accept header valued with yaml media type
> > like "text/yaml" for some implementations.
> >
> > Side note: the impl does not impose any body writer to be integrable in
> > any environment and does not enforce yaml as well cause it is not part of
> > the core of microprofile (and hopefully will never be) so no reason to
> > import a lib (which can be heavy and potentially with vulnerabilities +
> > work for the users to maintain it) for that.
> >
> > 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. 29 nov. 2018 à 17:50, Ivan Junckes Filho 
> > a écrit :
> >
> >> Hey guys, I think I found a bug in OpenAPI implementation.
> >>
> >> The spec says:
> >> "The default format of the /openapi endpoint is YAML."
> >>
> >> But when I try to access /openapi it returns JSON by default.
> >>
> >> This is not correct.
> >>
> >> Also how can I access yaml if it is not default?
> >>
> >
>


-- 
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.linkedin.com/in/monsonhaefel/

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

Hello Ivan,

this is actually not exactly the case, the impl is writer agnostic and
fully relies on JAXRS for that so if you have a body writer which matches
OpenAPI and returns yaml by default or
which prefer yaml over json then you will have the behavior you describe.

To get yaml you can send the Accept header valued with yaml media type like
"text/yaml" for some implementations.

Side note: the impl does not impose any body writer to be integrable in any
environment and does not enforce yaml as well cause it is not part of the
core of microprofile (and hopefully will never be) so no reason to import a
lib (which can be heavy and potentially with vulnerabilities + work for the
users to maintain it) for that.

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



Le jeu. 29 nov. 2018 à 17:50, Ivan Junckes Filho  a
écrit :

> Hey guys, I think I found a bug in OpenAPI implementation.
>
> The spec says:
> "The default format of the /openapi endpoint is YAML."
>
> But when I try to access /openapi it returns JSON by default.
>
> This is not correct.
>
> Also how can I access yaml if it is not default?
>

Re: Microprofile OpenAPI

[Ivan Junckes Filho]

Hey Romain, take a look on:

https://download.eclipse.org/microprofile/microprofile-open-api-1.0/microprofile-openapi-spec.html#_content_format

It is clear for me there, that the default should be yaml.

On Thu, Nov 29, 2018 at 2:58 PM Romain Manni-Bucau 
wrote:

> Hello Ivan,
>
> this is actually not exactly the case, the impl is writer agnostic and
> fully relies on JAXRS for that so if you have a body writer which matches
> OpenAPI and returns yaml by default or
> which prefer yaml over json then you will have the behavior you describe.
>
> To get yaml you can send the Accept header valued with yaml media type
> like "text/yaml" for some implementations.
>
> Side note: the impl does not impose any body writer to be integrable in
> any environment and does not enforce yaml as well cause it is not part of
> the core of microprofile (and hopefully will never be) so no reason to
> import a lib (which can be heavy and potentially with vulnerabilities +
> work for the users to maintain it) for that.
>
> 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. 29 nov. 2018 à 17:50, Ivan Junckes Filho 
> a écrit :
>
>> Hey guys, I think I found a bug in OpenAPI implementation.
>>
>> The spec says:
>> "The default format of the /openapi endpoint is YAML."
>>
>> But when I try to access /openapi it returns JSON by default.
>>
>> This is not correct.
>>
>> Also how can I access yaml if it is not default?
>>
>

Microprofile OpenAPI

[Ivan Junckes Filho]

Hey guys, I think I found a bug in OpenAPI implementation.

The spec says:
"The default format of the /openapi endpoint is YAML."

But when I try to access /openapi it returns JSON by default.

This is not correct.

Also how can I access yaml if it is not default?