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 <[email protected]> wrote: > > > On Fri, Nov 30, 2018 at 2:34 PM Richard Monson-Haefel < > [email protected]> 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 < >> [email protected]> >> 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 < >> [email protected]> >> > 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 < >> [email protected]> >> > > 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 < >> > [email protected]> >> > >> 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 < >> > [email protected]> >> > >>> a écrit : >> > >>> >> > >>>> @Romain Manni-Bucau <[email protected]> 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 < >> > >>>> [email protected]> 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 (< >> > >>>>> [email protected]>) >> > >>>>> 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 < >> > >>>>> [email protected]> >> > >>>>> > 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 < >> [email protected] >> > > >> > >>>>> 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 < >> > >>>>> > > [email protected]> >> > >>>>> > > > 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 < >> > >>>>> > > >> [email protected]> 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 < >> > >>>>> > > >>> [email protected]> 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)
