Le ven. 30 nov. 2018 à 18:23, César Hernández Mendoza <cesargu...@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 (<
> rmannibu...@gmail.com>) escribió:
>
> > 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/
> > > > >
> > > >
> > >
> >
>
>
> --
> Atentamente:
> César Hernández Mendoza.
>

Reply via email to