Le ven. 30 nov. 2018 à 17:45, Ivan Junckes Filho <ivanjunc...@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 <rmannibu...@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 < > > 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/ > > > > > >
