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 <monsonhae...@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 <ivanjunc...@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 < > 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. > > >>>>> > > >>>> > > > > > -- > Richard Monson-Haefel > https://twitter.com/rmonson > https://www.linkedin.com/in/monsonhaefel/ >
