You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Ivan Junckes Filho <iv...@gmail.com> on 2018/11/29 16:49:49 UTC
Microprofile OpenAPI
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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <iv...@gmail.com> 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 <rm...@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 <jo...@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 <
>> rmannibucau@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.gallimore@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 <
>> >>> ivanjunckes@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <iv...@gmail.com> 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 <rm...@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 <jo...@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 <
>> rmannibucau@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.gallimore@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 <
>> >>> ivanjunckes@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Well, I don't aim to have an argument here but please also consider that I
can ask as well why you (not sure who is "people" cause I see mainly 1
voice here which vendor voice) woudln't respect user feedback which is
regularly pro json in several companies - I know the spec picked yaml for
"other$" reasons.
Also note that, as I mentionned, the implementation is now compliant to the
spec, so not really sure the follow up to give to that topic.
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:25, Ivan Junckes Filho <iv...@gmail.com> a
écrit :
> The goal for this is to implement Microprofile Specifications. So what the
> Microprofile community decides is important and needs to be followed. Of
> course everyone has a voice there and you clearly spoke up there which is
> great. You think it is not the best approach, but people there until now
> think it is. So why not respect what they decide?
>
> It would be compatible if you put yaml by default and choose to make json
> default with a property. But making json default and adding extra configs
> to make yaml default is not what the spec defines.
>
> This is the standard:
> "The default format of the /openapi endpoint is YAML.
>
> Anything different than this is what you think is the best and not a
> consensus in the MicroProfile community. "Stupid" is a very personal
> opinion and doesn't reflect what people think about it there, neither my
> opinion.
>
> I again, think we should follow what the standard is and change later if
> the community decides so.
>
> On Fri, Nov 30, 2018 at 2:14 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> 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 <iv...@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 <
>>> rmannibucau@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 <iv...@gmail.com>
>>>> a écrit :
>>>>
>>>>> @Romain Manni-Bucau <rm...@gmail.com> 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 <
>>>>> cesarguate@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 (<
>>>>>> ivanjunckes@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 <
>>>>>> rmannibucau@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 <jo...@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 <
>>>>>> > > rmannibucau@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.gallimore@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 <
>>>>>> > > >>> ivanjunckes@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
Posted by Raymond Auge <ra...@liferay.com>.
I do personally find it very weird that MP spec would prefer YAML over JSON
when there is no YAML otherwise defined as part of the MP profile!
If I wanted to build a minimal MP it means I have to add a YAML impl when
the stack already defines JSON to be part of the stack? It makes little
sense.
Just my 2 cents,
- Ray
On Fri, Nov 30, 2018 at 12:10 PM Ivan Junckes Filho <iv...@gmail.com>
wrote:
>
>
> On Fri, Nov 30, 2018 at 2:34 PM Richard Monson-Haefel <
> monsonhaefel@gmail.com> wrote:
>
>> When you are setting up a MP Rest Client, there are certain annotations
>> that are required, right? Is it possible to have the TomEE code detect
>> these MP annotations and change the default to yaml automatically? That
>> way, yaml is only the default if you are communicating with MP-conformant
>> systems. Just looking for a compromise here.
>>
> I still think this is an alternative and not the standard. Also, I don't
> think this would be a good solution to tie this to a microprofile lib.
>
>
>>
>> On Fri, Nov 30, 2018 at 10:25 AM Ivan Junckes Filho <
>> ivanjunckes@gmail.com>
>> wrote:
>>
>> > The goal for this is to implement Microprofile Specifications. So what
>> the
>> > Microprofile community decides is important and needs to be followed. Of
>> > course everyone has a voice there and you clearly spoke up there which
>> is
>> > great. You think it is not the best approach, but people there until now
>> > think it is. So why not respect what they decide?
>> >
>> > It would be compatible if you put yaml by default and choose to make
>> json
>> > default with a property. But making json default and adding extra
>> configs
>> > to make yaml default is not what the spec defines.
>> >
>> > This is the standard:
>> > "The default format of the /openapi endpoint is YAML.
>> >
>> > Anything different than this is what you think is the best and not a
>> > consensus in the MicroProfile community. "Stupid" is a very personal
>> > opinion and doesn't reflect what people think about it there, neither my
>> > opinion.
>> >
>> > I again, think we should follow what the standard is and change later if
>> > the community decides so.
>> >
>> > On Fri, Nov 30, 2018 at 2:14 PM Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>> > wrote:
>> >
>> > > 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 <
>> ivanjunckes@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 <
>> > rmannibucau@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 <
>> > ivanjunckes@gmail.com>
>> > >>> a écrit :
>> > >>>
>> > >>>> @Romain Manni-Bucau <rm...@gmail.com> 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 <
>> > >>>> cesarguate@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 (<
>> > >>>>> ivanjunckes@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 <
>> > >>>>> rmannibucau@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 <
>> johndament@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 <
>> > >>>>> > > rmannibucau@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.gallimore@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 <
>> > >>>>> > > >>> ivanjunckes@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/
>>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
Re: Microprofile OpenAPI
Posted by Ivan Junckes Filho <iv...@gmail.com>.
On Fri, Nov 30, 2018 at 2:34 PM Richard Monson-Haefel <
monsonhaefel@gmail.com> wrote:
> When you are setting up a MP Rest Client, there are certain annotations
> that are required, right? Is it possible to have the TomEE code detect
> these MP annotations and change the default to yaml automatically? That
> way, yaml is only the default if you are communicating with MP-conformant
> systems. Just looking for a compromise here.
>
I still think this is an alternative and not the standard. Also, I don't
think this would be a good solution to tie this to a microprofile lib.
>
> On Fri, Nov 30, 2018 at 10:25 AM Ivan Junckes Filho <ivanjunckes@gmail.com
> >
> wrote:
>
> > The goal for this is to implement Microprofile Specifications. So what
> the
> > Microprofile community decides is important and needs to be followed. Of
> > course everyone has a voice there and you clearly spoke up there which is
> > great. You think it is not the best approach, but people there until now
> > think it is. So why not respect what they decide?
> >
> > It would be compatible if you put yaml by default and choose to make json
> > default with a property. But making json default and adding extra configs
> > to make yaml default is not what the spec defines.
> >
> > This is the standard:
> > "The default format of the /openapi endpoint is YAML.
> >
> > Anything different than this is what you think is the best and not a
> > consensus in the MicroProfile community. "Stupid" is a very personal
> > opinion and doesn't reflect what people think about it there, neither my
> > opinion.
> >
> > I again, think we should follow what the standard is and change later if
> > the community decides so.
> >
> > On Fri, Nov 30, 2018 at 2:14 PM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > 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 <
> ivanjunckes@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 <
> > rmannibucau@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 <
> > ivanjunckes@gmail.com>
> > >>> a écrit :
> > >>>
> > >>>> @Romain Manni-Bucau <rm...@gmail.com> 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 <
> > >>>> cesarguate@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 (<
> > >>>>> ivanjunckes@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 <
> > >>>>> rmannibucau@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 <
> johndament@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 <
> > >>>>> > > rmannibucau@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.gallimore@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 <
> > >>>>> > > >>> ivanjunckes@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Well, I don't aim to have an argument here but please also consider that I
can ask as well why you (not sure who is "people" cause I see mainly 1
voice here which vendor voice) woudln't respect user feedback which is
regularly pro json in several companies - I know the spec picked yaml for
"other$" reasons.
Also note that, as I mentionned, the implementation is now compliant to the
spec, so not really sure the follow up to give to that topic.
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:25, Ivan Junckes Filho <iv...@gmail.com> a
écrit :
> The goal for this is to implement Microprofile Specifications. So what the
> Microprofile community decides is important and needs to be followed. Of
> course everyone has a voice there and you clearly spoke up there which is
> great. You think it is not the best approach, but people there until now
> think it is. So why not respect what they decide?
>
> It would be compatible if you put yaml by default and choose to make json
> default with a property. But making json default and adding extra configs
> to make yaml default is not what the spec defines.
>
> This is the standard:
> "The default format of the /openapi endpoint is YAML.
>
> Anything different than this is what you think is the best and not a
> consensus in the MicroProfile community. "Stupid" is a very personal
> opinion and doesn't reflect what people think about it there, neither my
> opinion.
>
> I again, think we should follow what the standard is and change later if
> the community decides so.
>
> On Fri, Nov 30, 2018 at 2:14 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> 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 <iv...@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 <
>>> rmannibucau@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 <iv...@gmail.com>
>>>> a écrit :
>>>>
>>>>> @Romain Manni-Bucau <rm...@gmail.com> 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 <
>>>>> cesarguate@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 (<
>>>>>> ivanjunckes@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 <
>>>>>> rmannibucau@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 <jo...@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 <
>>>>>> > > rmannibucau@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.gallimore@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 <
>>>>>> > > >>> ivanjunckes@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le ven. 30 nov. 2018 à 18:23, César Hernández Mendoza <ce...@gmail.com>
a écrit :
> Hi all,
>
> Trying to keep the focus of this thread base on the "tangible" artifacts
> (Spec, TCK, etc).
>
> Correct me if I'm wrong but if currently the spec state YAML but the TCK is
> missing the test to enforce this.
> Then, in this case, I think we should fix first the TCK to comply with the
> spec as it's right now.
>
This is not the case but an utility in the TCK allows to bypass it but they
explicitly test yaml and json more or less everywhere.
The "yaml is the default" is explained by the tck, there are comments
explaining there is not standard mime type for yaml...so it must be the
default (I don't think it is the opposite way, it would have been
standardized the spec would have stated it 1-1 I assume)
>
> I see there are a couple of MP issues still open about this issue that can
> update or not later the fix in the TCK.
>
>
>
> [1] https://github.com/eclipse/microprofile-open-api/issues/228
> [2] https://github.com/eclipse/microprofile-open-api/issues/302
>
>
> El vie., 30 nov. 2018 a las 10:49, Romain Manni-Bucau (<
> rmannibucau@gmail.com>) escribió:
>
> > Le ven. 30 nov. 2018 à 17:45, Ivan Junckes Filho <iv...@gmail.com>
> a
> > écrit :
> >
> > > Just to be clear, this is not about a vendor opinion, it is my opinion
> > and
> > > the spec says that clearly so it is about a community opinion.
> > >
> > > Also see comments from other people from IBM and RedHat that
> participate
> > > actively in the spec.
> > >
> > >
> >
> https://github.com/eclipse/microprofile-open-api/issues/228#issuecomment-431889411
> > >
> > >
> >
> https://github.com/eclipse/microprofile-open-api/issues/302#issuecomment-443034856
> > >
> > >
> >
> https://github.com/eclipse/microprofile-open-api/issues/228#issuecomment-431895833
> > >
> > >
> >
> https://github.com/eclipse/microprofile-open-api/issues/228#issuecomment-432038154
> > >
> > > When you say it is a 1 voice opinion that is not fair.
> > >
> >
> > Well it is all about vendors, was my point. Got very bad feedbacks cause
> > the platform is becoming inconsistent and broken cause each spec is done
> > independently of others and I share that very strongly
> > so I ensured all impl @geronimo don't impose it at users. Having used it
> > recently in softwares requiring some industrialization (I'm strongly
> > thinking to security scans here) I really appreciated to be able to drop
> > not used parts.
> >
> >
> > >
> > > This comment "I know the spec picked yaml for "other$" reasons." is
> also
> > > very offensive and may be wrong. I have been participating on those
> calls
> > > and anyone really is able to participate and help decide things in the
> > > spec.
> > >
> > > >> why is current impl not compliant?
> > >
> > > Like I said yaml is not default and that diverges from the spec. Adding
> > > yaml as default if we add jackson yaml won't make it default as well,
> it
> > > will be still an alternative.
> > >
> >
> > Ok, then this is this assumption which is wrong and where this thread
> > became split.
> >
> >
> > >
> > >
> > >
> > > On Fri, Nov 30, 2018 at 2:40 PM Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > > > Ok, will repeat a third time hoping it is a mail crossing issue: why
> is
> > > > current impl not compliant?
> > > >
> > > > 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:34, Richard Monson-Haefel <
> > > > monsonhaefel@gmail.com>
> > > > a écrit :
> > > >
> > > > > When you are setting up a MP Rest Client, there are certain
> > annotations
> > > > > that are required, right? Is it possible to have the TomEE code
> > detect
> > > > > these MP annotations and change the default to yaml automatically?
> > > That
> > > > > way, yaml is only the default if you are communicating with
> > > MP-conformant
> > > > > systems. Just looking for a compromise here.
> > > > >
> > > > > On Fri, Nov 30, 2018 at 10:25 AM Ivan Junckes Filho <
> > > > ivanjunckes@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > The goal for this is to implement Microprofile Specifications. So
> > > what
> > > > > the
> > > > > > Microprofile community decides is important and needs to be
> > followed.
> > > > Of
> > > > > > course everyone has a voice there and you clearly spoke up there
> > > which
> > > > is
> > > > > > great. You think it is not the best approach, but people there
> > until
> > > > now
> > > > > > think it is. So why not respect what they decide?
> > > > > >
> > > > > > It would be compatible if you put yaml by default and choose to
> > make
> > > > json
> > > > > > default with a property. But making json default and adding extra
> > > > configs
> > > > > > to make yaml default is not what the spec defines.
> > > > > >
> > > > > > This is the standard:
> > > > > > "The default format of the /openapi endpoint is YAML.
> > > > > >
> > > > > > Anything different than this is what you think is the best and
> not
> > a
> > > > > > consensus in the MicroProfile community. "Stupid" is a very
> > personal
> > > > > > opinion and doesn't reflect what people think about it there,
> > neither
> > > > my
> > > > > > opinion.
> > > > > >
> > > > > > I again, think we should follow what the standard is and change
> > later
> > > > if
> > > > > > the community decides so.
> > > > > >
> > > > > > On Fri, Nov 30, 2018 at 2:14 PM Romain Manni-Bucau <
> > > > > rmannibucau@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > 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 <
> > > > > ivanjunckes@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 <
> > > > > > rmannibucau@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 <
> > > > > > ivanjunckes@gmail.com>
> > > > > > >>> a écrit :
> > > > > > >>>
> > > > > > >>>> @Romain Manni-Bucau <rm...@gmail.com> 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 <
> > > > > > >>>> cesarguate@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 (<
> > > > > > >>>>> ivanjunckes@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 <
> > > > > > >>>>> rmannibucau@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 <
> > > > > johndament@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 <
> > > > > > >>>>> > > rmannibucau@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.gallimore@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
> <
> > > > > > >>>>> > > >>> ivanjunckes@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
Posted by César Hernández Mendoza <ce...@gmail.com>.
Hi all,
Trying to keep the focus of this thread base on the "tangible" artifacts
(Spec, TCK, etc).
Correct me if I'm wrong but if currently the spec state YAML but the TCK is
missing the test to enforce this.
Then, in this case, I think we should fix first the TCK to comply with the
spec as it's right now.
I see there are a couple of MP issues still open about this issue that can
update or not later the fix in the TCK.
[1] https://github.com/eclipse/microprofile-open-api/issues/228
[2] https://github.com/eclipse/microprofile-open-api/issues/302
El vie., 30 nov. 2018 a las 10:49, Romain Manni-Bucau (<
rmannibucau@gmail.com>) escribió:
> Le ven. 30 nov. 2018 à 17:45, Ivan Junckes Filho <iv...@gmail.com> a
> écrit :
>
> > Just to be clear, this is not about a vendor opinion, it is my opinion
> and
> > the spec says that clearly so it is about a community opinion.
> >
> > Also see comments from other people from IBM and RedHat that participate
> > actively in the spec.
> >
> >
> https://github.com/eclipse/microprofile-open-api/issues/228#issuecomment-431889411
> >
> >
> https://github.com/eclipse/microprofile-open-api/issues/302#issuecomment-443034856
> >
> >
> https://github.com/eclipse/microprofile-open-api/issues/228#issuecomment-431895833
> >
> >
> https://github.com/eclipse/microprofile-open-api/issues/228#issuecomment-432038154
> >
> > When you say it is a 1 voice opinion that is not fair.
> >
>
> Well it is all about vendors, was my point. Got very bad feedbacks cause
> the platform is becoming inconsistent and broken cause each spec is done
> independently of others and I share that very strongly
> so I ensured all impl @geronimo don't impose it at users. Having used it
> recently in softwares requiring some industrialization (I'm strongly
> thinking to security scans here) I really appreciated to be able to drop
> not used parts.
>
>
> >
> > This comment "I know the spec picked yaml for "other$" reasons." is also
> > very offensive and may be wrong. I have been participating on those calls
> > and anyone really is able to participate and help decide things in the
> > spec.
> >
> > >> why is current impl not compliant?
> >
> > Like I said yaml is not default and that diverges from the spec. Adding
> > yaml as default if we add jackson yaml won't make it default as well, it
> > will be still an alternative.
> >
>
> Ok, then this is this assumption which is wrong and where this thread
> became split.
>
>
> >
> >
> >
> > On Fri, Nov 30, 2018 at 2:40 PM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > Ok, will repeat a third time hoping it is a mail crossing issue: why is
> > > current impl not compliant?
> > >
> > > 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:34, Richard Monson-Haefel <
> > > monsonhaefel@gmail.com>
> > > a écrit :
> > >
> > > > When you are setting up a MP Rest Client, there are certain
> annotations
> > > > that are required, right? Is it possible to have the TomEE code
> detect
> > > > these MP annotations and change the default to yaml automatically?
> > That
> > > > way, yaml is only the default if you are communicating with
> > MP-conformant
> > > > systems. Just looking for a compromise here.
> > > >
> > > > On Fri, Nov 30, 2018 at 10:25 AM Ivan Junckes Filho <
> > > ivanjunckes@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > The goal for this is to implement Microprofile Specifications. So
> > what
> > > > the
> > > > > Microprofile community decides is important and needs to be
> followed.
> > > Of
> > > > > course everyone has a voice there and you clearly spoke up there
> > which
> > > is
> > > > > great. You think it is not the best approach, but people there
> until
> > > now
> > > > > think it is. So why not respect what they decide?
> > > > >
> > > > > It would be compatible if you put yaml by default and choose to
> make
> > > json
> > > > > default with a property. But making json default and adding extra
> > > configs
> > > > > to make yaml default is not what the spec defines.
> > > > >
> > > > > This is the standard:
> > > > > "The default format of the /openapi endpoint is YAML.
> > > > >
> > > > > Anything different than this is what you think is the best and not
> a
> > > > > consensus in the MicroProfile community. "Stupid" is a very
> personal
> > > > > opinion and doesn't reflect what people think about it there,
> neither
> > > my
> > > > > opinion.
> > > > >
> > > > > I again, think we should follow what the standard is and change
> later
> > > if
> > > > > the community decides so.
> > > > >
> > > > > On Fri, Nov 30, 2018 at 2:14 PM Romain Manni-Bucau <
> > > > rmannibucau@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > 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 <
> > > > ivanjunckes@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 <
> > > > > rmannibucau@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 <
> > > > > ivanjunckes@gmail.com>
> > > > > >>> a écrit :
> > > > > >>>
> > > > > >>>> @Romain Manni-Bucau <rm...@gmail.com> 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 <
> > > > > >>>> cesarguate@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 (<
> > > > > >>>>> ivanjunckes@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 <
> > > > > >>>>> rmannibucau@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 <
> > > > johndament@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 <
> > > > > >>>>> > > rmannibucau@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.gallimore@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 <
> > > > > >>>>> > > >>> ivanjunckes@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le ven. 30 nov. 2018 à 17:45, Ivan Junckes Filho <iv...@gmail.com> a
écrit :
> Just to be clear, this is not about a vendor opinion, it is my opinion and
> the spec says that clearly so it is about a community opinion.
>
> Also see comments from other people from IBM and RedHat that participate
> actively in the spec.
>
> https://github.com/eclipse/microprofile-open-api/issues/228#issuecomment-431889411
>
> https://github.com/eclipse/microprofile-open-api/issues/302#issuecomment-443034856
>
> https://github.com/eclipse/microprofile-open-api/issues/228#issuecomment-431895833
>
> https://github.com/eclipse/microprofile-open-api/issues/228#issuecomment-432038154
>
> When you say it is a 1 voice opinion that is not fair.
>
Well it is all about vendors, was my point. Got very bad feedbacks cause
the platform is becoming inconsistent and broken cause each spec is done
independently of others and I share that very strongly
so I ensured all impl @geronimo don't impose it at users. Having used it
recently in softwares requiring some industrialization (I'm strongly
thinking to security scans here) I really appreciated to be able to drop
not used parts.
>
> This comment "I know the spec picked yaml for "other$" reasons." is also
> very offensive and may be wrong. I have been participating on those calls
> and anyone really is able to participate and help decide things in the
> spec.
>
> >> why is current impl not compliant?
>
> Like I said yaml is not default and that diverges from the spec. Adding
> yaml as default if we add jackson yaml won't make it default as well, it
> will be still an alternative.
>
Ok, then this is this assumption which is wrong and where this thread
became split.
>
>
>
> On Fri, Nov 30, 2018 at 2:40 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Ok, will repeat a third time hoping it is a mail crossing issue: why is
> > current impl not compliant?
> >
> > 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:34, Richard Monson-Haefel <
> > monsonhaefel@gmail.com>
> > a écrit :
> >
> > > When you are setting up a MP Rest Client, there are certain annotations
> > > that are required, right? Is it possible to have the TomEE code detect
> > > these MP annotations and change the default to yaml automatically?
> That
> > > way, yaml is only the default if you are communicating with
> MP-conformant
> > > systems. Just looking for a compromise here.
> > >
> > > On Fri, Nov 30, 2018 at 10:25 AM Ivan Junckes Filho <
> > ivanjunckes@gmail.com
> > > >
> > > wrote:
> > >
> > > > The goal for this is to implement Microprofile Specifications. So
> what
> > > the
> > > > Microprofile community decides is important and needs to be followed.
> > Of
> > > > course everyone has a voice there and you clearly spoke up there
> which
> > is
> > > > great. You think it is not the best approach, but people there until
> > now
> > > > think it is. So why not respect what they decide?
> > > >
> > > > It would be compatible if you put yaml by default and choose to make
> > json
> > > > default with a property. But making json default and adding extra
> > configs
> > > > to make yaml default is not what the spec defines.
> > > >
> > > > This is the standard:
> > > > "The default format of the /openapi endpoint is YAML.
> > > >
> > > > Anything different than this is what you think is the best and not a
> > > > consensus in the MicroProfile community. "Stupid" is a very personal
> > > > opinion and doesn't reflect what people think about it there, neither
> > my
> > > > opinion.
> > > >
> > > > I again, think we should follow what the standard is and change later
> > if
> > > > the community decides so.
> > > >
> > > > On Fri, Nov 30, 2018 at 2:14 PM Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > > wrote:
> > > >
> > > > > 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 <
> > > ivanjunckes@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 <
> > > > rmannibucau@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 <
> > > > ivanjunckes@gmail.com>
> > > > >>> a écrit :
> > > > >>>
> > > > >>>> @Romain Manni-Bucau <rm...@gmail.com> 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 <
> > > > >>>> cesarguate@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 (<
> > > > >>>>> ivanjunckes@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 <
> > > > >>>>> rmannibucau@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 <
> > > johndament@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 <
> > > > >>>>> > > rmannibucau@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.gallimore@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 <
> > > > >>>>> > > >>> ivanjunckes@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
Posted by Ivan Junckes Filho <iv...@gmail.com>.
Just to be clear, this is not about a vendor opinion, it is my opinion and
the spec says that clearly so it is about a community opinion.
Also see comments from other people from IBM and RedHat that participate
actively in the spec.
https://github.com/eclipse/microprofile-open-api/issues/228#issuecomment-431889411
https://github.com/eclipse/microprofile-open-api/issues/302#issuecomment-443034856
https://github.com/eclipse/microprofile-open-api/issues/228#issuecomment-431895833
https://github.com/eclipse/microprofile-open-api/issues/228#issuecomment-432038154
When you say it is a 1 voice opinion that is not fair.
This comment "I know the spec picked yaml for "other$" reasons." is also
very offensive and may be wrong. I have been participating on those calls
and anyone really is able to participate and help decide things in the spec.
>> why is current impl not compliant?
Like I said yaml is not default and that diverges from the spec. Adding
yaml as default if we add jackson yaml won't make it default as well, it
will be still an alternative.
On Fri, Nov 30, 2018 at 2:40 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Ok, will repeat a third time hoping it is a mail crossing issue: why is
> current impl not compliant?
>
> 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:34, Richard Monson-Haefel <
> monsonhaefel@gmail.com>
> a écrit :
>
> > When you are setting up a MP Rest Client, there are certain annotations
> > that are required, right? Is it possible to have the TomEE code detect
> > these MP annotations and change the default to yaml automatically? That
> > way, yaml is only the default if you are communicating with MP-conformant
> > systems. Just looking for a compromise here.
> >
> > On Fri, Nov 30, 2018 at 10:25 AM Ivan Junckes Filho <
> ivanjunckes@gmail.com
> > >
> > wrote:
> >
> > > The goal for this is to implement Microprofile Specifications. So what
> > the
> > > Microprofile community decides is important and needs to be followed.
> Of
> > > course everyone has a voice there and you clearly spoke up there which
> is
> > > great. You think it is not the best approach, but people there until
> now
> > > think it is. So why not respect what they decide?
> > >
> > > It would be compatible if you put yaml by default and choose to make
> json
> > > default with a property. But making json default and adding extra
> configs
> > > to make yaml default is not what the spec defines.
> > >
> > > This is the standard:
> > > "The default format of the /openapi endpoint is YAML.
> > >
> > > Anything different than this is what you think is the best and not a
> > > consensus in the MicroProfile community. "Stupid" is a very personal
> > > opinion and doesn't reflect what people think about it there, neither
> my
> > > opinion.
> > >
> > > I again, think we should follow what the standard is and change later
> if
> > > the community decides so.
> > >
> > > On Fri, Nov 30, 2018 at 2:14 PM Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > > > 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 <
> > ivanjunckes@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 <
> > > rmannibucau@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 <
> > > ivanjunckes@gmail.com>
> > > >>> a écrit :
> > > >>>
> > > >>>> @Romain Manni-Bucau <rm...@gmail.com> 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 <
> > > >>>> cesarguate@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 (<
> > > >>>>> ivanjunckes@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 <
> > > >>>>> rmannibucau@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 <
> > johndament@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 <
> > > >>>>> > > rmannibucau@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.gallimore@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 <
> > > >>>>> > > >>> ivanjunckes@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Ok, will repeat a third time hoping it is a mail crossing issue: why is
current impl not compliant?
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:34, Richard Monson-Haefel <mo...@gmail.com>
a écrit :
> When you are setting up a MP Rest Client, there are certain annotations
> that are required, right? Is it possible to have the TomEE code detect
> these MP annotations and change the default to yaml automatically? That
> way, yaml is only the default if you are communicating with MP-conformant
> systems. Just looking for a compromise here.
>
> On Fri, Nov 30, 2018 at 10:25 AM Ivan Junckes Filho <ivanjunckes@gmail.com
> >
> wrote:
>
> > The goal for this is to implement Microprofile Specifications. So what
> the
> > Microprofile community decides is important and needs to be followed. Of
> > course everyone has a voice there and you clearly spoke up there which is
> > great. You think it is not the best approach, but people there until now
> > think it is. So why not respect what they decide?
> >
> > It would be compatible if you put yaml by default and choose to make json
> > default with a property. But making json default and adding extra configs
> > to make yaml default is not what the spec defines.
> >
> > This is the standard:
> > "The default format of the /openapi endpoint is YAML.
> >
> > Anything different than this is what you think is the best and not a
> > consensus in the MicroProfile community. "Stupid" is a very personal
> > opinion and doesn't reflect what people think about it there, neither my
> > opinion.
> >
> > I again, think we should follow what the standard is and change later if
> > the community decides so.
> >
> > On Fri, Nov 30, 2018 at 2:14 PM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > 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 <
> ivanjunckes@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 <
> > rmannibucau@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 <
> > ivanjunckes@gmail.com>
> > >>> a écrit :
> > >>>
> > >>>> @Romain Manni-Bucau <rm...@gmail.com> 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 <
> > >>>> cesarguate@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 (<
> > >>>>> ivanjunckes@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 <
> > >>>>> rmannibucau@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 <
> johndament@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 <
> > >>>>> > > rmannibucau@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.gallimore@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 <
> > >>>>> > > >>> ivanjunckes@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
Posted by Ivan Junckes Filho <iv...@gmail.com>.
On Fri, Nov 30, 2018 at 2:34 PM Richard Monson-Haefel <
monsonhaefel@gmail.com> wrote:
> When you are setting up a MP Rest Client, there are certain annotations
> that are required, right? Is it possible to have the TomEE code detect
> these MP annotations and change the default to yaml automatically? That
> way, yaml is only the default if you are communicating with MP-conformant
> systems. Just looking for a compromise here.
>
I still think this is an alternative and not the standard. Also, I don't
think this would be a good solution to tie this to a microprofile lib.
>
> On Fri, Nov 30, 2018 at 10:25 AM Ivan Junckes Filho <ivanjunckes@gmail.com
> >
> wrote:
>
> > The goal for this is to implement Microprofile Specifications. So what
> the
> > Microprofile community decides is important and needs to be followed. Of
> > course everyone has a voice there and you clearly spoke up there which is
> > great. You think it is not the best approach, but people there until now
> > think it is. So why not respect what they decide?
> >
> > It would be compatible if you put yaml by default and choose to make json
> > default with a property. But making json default and adding extra configs
> > to make yaml default is not what the spec defines.
> >
> > This is the standard:
> > "The default format of the /openapi endpoint is YAML.
> >
> > Anything different than this is what you think is the best and not a
> > consensus in the MicroProfile community. "Stupid" is a very personal
> > opinion and doesn't reflect what people think about it there, neither my
> > opinion.
> >
> > I again, think we should follow what the standard is and change later if
> > the community decides so.
> >
> > On Fri, Nov 30, 2018 at 2:14 PM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > 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 <
> ivanjunckes@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 <
> > rmannibucau@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 <
> > ivanjunckes@gmail.com>
> > >>> a écrit :
> > >>>
> > >>>> @Romain Manni-Bucau <rm...@gmail.com> 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 <
> > >>>> cesarguate@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 (<
> > >>>>> ivanjunckes@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 <
> > >>>>> rmannibucau@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 <
> johndament@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 <
> > >>>>> > > rmannibucau@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.gallimore@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 <
> > >>>>> > > >>> ivanjunckes@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
Posted by Richard Monson-Haefel <mo...@gmail.com>.
When you are setting up a MP Rest Client, there are certain annotations
that are required, right? Is it possible to have the TomEE code detect
these MP annotations and change the default to yaml automatically? That
way, yaml is only the default if you are communicating with MP-conformant
systems. Just looking for a compromise here.
On Fri, Nov 30, 2018 at 10:25 AM Ivan Junckes Filho <iv...@gmail.com>
wrote:
> The goal for this is to implement Microprofile Specifications. So what the
> Microprofile community decides is important and needs to be followed. Of
> course everyone has a voice there and you clearly spoke up there which is
> great. You think it is not the best approach, but people there until now
> think it is. So why not respect what they decide?
>
> It would be compatible if you put yaml by default and choose to make json
> default with a property. But making json default and adding extra configs
> to make yaml default is not what the spec defines.
>
> This is the standard:
> "The default format of the /openapi endpoint is YAML.
>
> Anything different than this is what you think is the best and not a
> consensus in the MicroProfile community. "Stupid" is a very personal
> opinion and doesn't reflect what people think about it there, neither my
> opinion.
>
> I again, think we should follow what the standard is and change later if
> the community decides so.
>
> On Fri, Nov 30, 2018 at 2:14 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > 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 <iv...@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 <
> rmannibucau@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 <
> ivanjunckes@gmail.com>
> >>> a écrit :
> >>>
> >>>> @Romain Manni-Bucau <rm...@gmail.com> 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 <
> >>>> cesarguate@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 (<
> >>>>> ivanjunckes@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 <
> >>>>> rmannibucau@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 <johndament@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 <
> >>>>> > > rmannibucau@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.gallimore@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 <
> >>>>> > > >>> ivanjunckes@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
Posted by Ivan Junckes Filho <iv...@gmail.com>.
The goal for this is to implement Microprofile Specifications. So what the
Microprofile community decides is important and needs to be followed. Of
course everyone has a voice there and you clearly spoke up there which is
great. You think it is not the best approach, but people there until now
think it is. So why not respect what they decide?
It would be compatible if you put yaml by default and choose to make json
default with a property. But making json default and adding extra configs
to make yaml default is not what the spec defines.
This is the standard:
"The default format of the /openapi endpoint is YAML.
Anything different than this is what you think is the best and not a
consensus in the MicroProfile community. "Stupid" is a very personal
opinion and doesn't reflect what people think about it there, neither my
opinion.
I again, think we should follow what the standard is and change later if
the community decides so.
On Fri, Nov 30, 2018 at 2:14 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> 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 <iv...@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 <rm...@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 <iv...@gmail.com>
>>> a écrit :
>>>
>>>> @Romain Manni-Bucau <rm...@gmail.com> 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 <
>>>> cesarguate@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 (<
>>>>> ivanjunckes@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 <
>>>>> rmannibucau@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 <jo...@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 <
>>>>> > > rmannibucau@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.gallimore@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 <
>>>>> > > >>> ivanjunckes@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
Posted by Ivan Junckes Filho <iv...@gmail.com>.
The goal for this is to implement Microprofile Specifications. So what the
Microprofile community decides is important and needs to be followed. Of
course everyone has a voice there and you clearly spoke up there which is
great. You think it is not the best approach, but people there until now
think it is. So why not respect what they decide?
It would be compatible if you put yaml by default and choose to make json
default with a property. But making json default and adding extra configs
to make yaml default is not what the spec defines.
This is the standard:
"The default format of the /openapi endpoint is YAML.
Anything different than this is what you think is the best and not a
consensus in the MicroProfile community. "Stupid" is a very personal
opinion and doesn't reflect what people think about it there, neither my
opinion.
I again, think we should follow what the standard is and change later if
the community decides so.
On Fri, Nov 30, 2018 at 2:14 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> 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 <iv...@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 <rm...@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 <iv...@gmail.com>
>>> a écrit :
>>>
>>>> @Romain Manni-Bucau <rm...@gmail.com> 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 <
>>>> cesarguate@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 (<
>>>>> ivanjunckes@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 <
>>>>> rmannibucau@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 <jo...@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 <
>>>>> > > rmannibucau@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.gallimore@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 <
>>>>> > > >>> ivanjunckes@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <iv...@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 <rm...@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 <iv...@gmail.com>
>> a écrit :
>>
>>> @Romain Manni-Bucau <rm...@gmail.com> 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 <
>>> cesarguate@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 (<
>>>> ivanjunckes@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 <
>>>> rmannibucau@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 <jo...@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 <
>>>> > > rmannibucau@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.gallimore@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 <
>>>> > > >>> ivanjunckes@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <iv...@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 <rm...@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 <iv...@gmail.com>
>> a écrit :
>>
>>> @Romain Manni-Bucau <rm...@gmail.com> 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 <
>>> cesarguate@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 (<
>>>> ivanjunckes@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 <
>>>> rmannibucau@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 <jo...@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 <
>>>> > > rmannibucau@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.gallimore@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 <
>>>> > > >>> ivanjunckes@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
Posted by Ivan Junckes Filho <iv...@gmail.com>.
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 <rm...@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 <iv...@gmail.com>
> a écrit :
>
>> @Romain Manni-Bucau <rm...@gmail.com> 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 <
>> cesarguate@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 (<
>>> ivanjunckes@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 <
>>> rmannibucau@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 <jo...@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 <
>>> > > rmannibucau@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.gallimore@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 <
>>> > > >>> ivanjunckes@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
Posted by Ivan Junckes Filho <iv...@gmail.com>.
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 <rm...@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 <iv...@gmail.com>
> a écrit :
>
>> @Romain Manni-Bucau <rm...@gmail.com> 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 <
>> cesarguate@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 (<
>>> ivanjunckes@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 <
>>> rmannibucau@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 <jo...@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 <
>>> > > rmannibucau@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.gallimore@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 <
>>> > > >>> ivanjunckes@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <iv...@gmail.com> a
écrit :
> @Romain Manni-Bucau <rm...@gmail.com> 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 <
> cesarguate@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 (<
>> ivanjunckes@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 <
>> rmannibucau@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 <jo...@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 <
>> > > rmannibucau@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.gallimore@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 <
>> > > >>> ivanjunckes@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <iv...@gmail.com> a
écrit :
> @Romain Manni-Bucau <rm...@gmail.com> 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 <
> cesarguate@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 (<
>> ivanjunckes@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 <
>> rmannibucau@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 <jo...@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 <
>> > > rmannibucau@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.gallimore@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 <
>> > > >>> ivanjunckes@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
Posted by Ivan Junckes Filho <iv...@gmail.com>.
@Romain Manni-Bucau <rm...@gmail.com> 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 <
cesarguate@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 (<
> ivanjunckes@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 <
> rmannibucau@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 <jo...@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 <
> > > rmannibucau@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.gallimore@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 <
> > > >>> ivanjunckes@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
Posted by Ivan Junckes Filho <iv...@gmail.com>.
@Romain Manni-Bucau <rm...@gmail.com> 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 <
cesarguate@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 (<
> ivanjunckes@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 <
> rmannibucau@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 <jo...@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 <
> > > rmannibucau@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.gallimore@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 <
> > > >>> ivanjunckes@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
Posted by César Hernández Mendoza <ce...@gmail.com>.
>
> 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 (<iv...@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 <rm...@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 <jo...@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 <
> > rmannibucau@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.gallimore@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 <
> > >>> ivanjunckes@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
Posted by Ivan Junckes Filho <iv...@gmail.com>.
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 <rm...@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 <jo...@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 <
> rmannibucau@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.gallimore@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 <
> >>> ivanjunckes@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
Posted by Ivan Junckes Filho <iv...@gmail.com>.
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 <rm...@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 <jo...@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 <
> rmannibucau@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.gallimore@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 <
> >>> ivanjunckes@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <jo...@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 <rm...@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.gallimore@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 <
>>> ivanjunckes@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <jo...@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 <rm...@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.gallimore@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 <
>>> ivanjunckes@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
Posted by "John D. Ament" <jo...@apache.org>.
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 <rm...@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.gallimore@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 <iv...@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
Posted by "John D. Ament" <jo...@apache.org>.
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 <rm...@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.gallimore@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 <iv...@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <jo...@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 <iv...@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <jo...@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 <iv...@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
Posted by Jonathan Gallimore <jo...@gmail.com>.
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 <iv...@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
Posted by Richard Monson-Haefel <mo...@gmail.com>.
True. It also doesn't mean that you not wrong. ;-)
On Thu, Nov 29, 2018 at 2:04 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Does not mean im not right ;)
>
> Le jeu. 29 nov. 2018 20:33, Richard Monson-Haefel <mo...@gmail.com>
> 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 <
> ivanjunckes@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 <
> > rmannibucau@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 <
> > ivanjunckes@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Does not mean im not right ;)
Le jeu. 29 nov. 2018 20:33, Richard Monson-Haefel <mo...@gmail.com>
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 <ivanjunckes@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 <
> rmannibucau@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 <
> ivanjunckes@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
Posted by Richard Monson-Haefel <mo...@gmail.com>.
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 <iv...@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 <rm...@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 <iv...@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
Posted by Ivan Junckes Filho <iv...@gmail.com>.
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 <rm...@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 <iv...@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?
>>
>
Re: Microprofile OpenAPI
Posted by Romain Manni-Bucau <rm...@gmail.com>.
https://github.com/eclipse/microprofile-open-api/issues/302
Side note - if i got the real question: tomee still needs to setup writers
correctly in mp common module if im not mistaken (to at least handle "q"
correctly if accepts has both json and yaml without weights)
Le jeu. 29 nov. 2018 18:22, Ivan Junckes Filho <iv...@gmail.com> a
écrit :
> Please share the ticket here Romain, so everybody can follow.
>
> On Thu, Nov 29, 2018 at 3:16 PM Bruno Baptista <br...@gmail.com> wrote:
>
>> +1 on getting an MP clarification on this.
>> Bruno Baptista
>> https://twitter.com/brunobat_
>>
>>
>> On 29/11/18 17:10, Romain Manni-Bucau wrote:
>>
>> Well the point is not much what the spec says, the implementation
>> supports all that since it lets the writer setup be done in the
>> integrations if needed.
>>
>> See it from the point of view of the lib:
>>
>> 1. 99% of the case will be json and json is well set up for microprofile
>> 2. yaml libs are different for most servers so no reason to impose one or
>> even make it conflicting
>>
>> => the integration needs to customize the writers if needed
>>
>> In the lib the most we could do is to not default to json if the
>> mediatype is null adding a config to default to yaml but often yaml writer
>> don't answer to text/yaml so not sure it would be good for users. I will
>> open a MP ticket about 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 à 18:07, Bruno Baptista <br...@gmail.com> a
>> écrit :
>>
>>> Hi Romain,
>>>
>>> Independent of the implementation details, if we have to specify the
>>> accept header with "text/yaml", the response in not *yaml by default*
>>> like the spec says... right?
>>>
>>> Ivan, Is there a test in the TCK to make sure the default is yaml?
>>>
>>> Cheers
>>> Bruno Baptista
>>> https://twitter.com/brunobat_
>>>
>>>
>>>
>>>
>>> On 29/11/18 16:58, 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 <iv...@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?
>>>>
>>>
Re: Microprofile OpenAPI
Posted by Ivan Junckes Filho <iv...@gmail.com>.
Please share the ticket here Romain, so everybody can follow.
On Thu, Nov 29, 2018 at 3:16 PM Bruno Baptista <br...@gmail.com> wrote:
> +1 on getting an MP clarification on this.
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
> On 29/11/18 17:10, Romain Manni-Bucau wrote:
>
> Well the point is not much what the spec says, the implementation supports
> all that since it lets the writer setup be done in the integrations if
> needed.
>
> See it from the point of view of the lib:
>
> 1. 99% of the case will be json and json is well set up for microprofile
> 2. yaml libs are different for most servers so no reason to impose one or
> even make it conflicting
>
> => the integration needs to customize the writers if needed
>
> In the lib the most we could do is to not default to json if the mediatype
> is null adding a config to default to yaml but often yaml writer don't
> answer to text/yaml so not sure it would be good for users. I will open a
> MP ticket about 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 à 18:07, Bruno Baptista <br...@gmail.com> a
> écrit :
>
>> Hi Romain,
>>
>> Independent of the implementation details, if we have to specify the
>> accept header with "text/yaml", the response in not *yaml by default*
>> like the spec says... right?
>>
>> Ivan, Is there a test in the TCK to make sure the default is yaml?
>>
>> Cheers
>> Bruno Baptista
>> https://twitter.com/brunobat_
>>
>>
>>
>>
>> On 29/11/18 16:58, 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 <iv...@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?
>>>
>>
Re: Microprofile OpenAPI
Posted by Bruno Baptista <br...@gmail.com>.
+1 on getting an MP clarification on this.
Bruno Baptista
https://twitter.com/brunobat_
On 29/11/18 17:10, Romain Manni-Bucau wrote:
> Well the point is not much what the spec says, the implementation
> supports all that since it lets the writer setup be done in the
> integrations if needed.
>
> See it from the point of view of the lib:
>
> 1. 99% of the case will be json and json is well set up for microprofile
> 2. yaml libs are different for most servers so no reason to impose one
> or even make it conflicting
>
> => the integration needs to customize the writers if needed
>
> In the lib the most we could do is to not default to json if the
> mediatype is null adding a config to default to yaml but often yaml
> writer don't answer to text/yaml so not sure it would be good for
> users. I will open a MP ticket about 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 à 18:07, Bruno Baptista <brunobat@gmail.com
> <ma...@gmail.com>> a écrit :
>
> Hi Romain,
>
> Independent of the implementation details, if we have to specify
> the accept header with "text/yaml", the response in not *yaml by
> default* like the spec says... right?
>
> Ivan, Is there a test in the TCK to make sure the default is yaml?
>
> Cheers
>
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
>
>
> On 29/11/18 16:58, 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
>> <ivanjunckes@gmail.com <ma...@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?
>>
Re: Microprofile OpenAPI
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Well the point is not much what the spec says, the implementation supports
all that since it lets the writer setup be done in the integrations if
needed.
See it from the point of view of the lib:
1. 99% of the case will be json and json is well set up for microprofile
2. yaml libs are different for most servers so no reason to impose one or
even make it conflicting
=> the integration needs to customize the writers if needed
In the lib the most we could do is to not default to json if the mediatype
is null adding a config to default to yaml but often yaml writer don't
answer to text/yaml so not sure it would be good for users. I will open a
MP ticket about 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 à 18:07, Bruno Baptista <br...@gmail.com> a écrit :
> Hi Romain,
>
> Independent of the implementation details, if we have to specify the
> accept header with "text/yaml", the response in not *yaml by default*
> like the spec says... right?
>
> Ivan, Is there a test in the TCK to make sure the default is yaml?
>
> Cheers
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
>
>
> On 29/11/18 16:58, 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 <iv...@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?
>>
>
Re: Microprofile OpenAPI
Posted by Bruno Baptista <br...@gmail.com>.
Hi Romain,
Independent of the implementation details, if we have to specify the
accept header with "text/yaml", the response in not *yaml by default*
like the spec says... right?
Ivan, Is there a test in the TCK to make sure the default is yaml?
Cheers
Bruno Baptista
https://twitter.com/brunobat_
On 29/11/18 16:58, 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
> <ivanjunckes@gmail.com <ma...@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?
>
Re: Microprofile OpenAPI
Posted by Ivan Junckes Filho <iv...@gmail.com>.
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 <rm...@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 <iv...@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?
>>
>
Re: Microprofile OpenAPI
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <iv...@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?
>
Re: Microprofile OpenAPI
Posted by Jonathan Gallimore <jo...@gmail.com>.
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 <iv...@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <iv...@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?
>