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