I think doing it on the model is something else as basically you already
merge detected properties, so you end up with only one.
At least that's what I do in Genson, I give preference to the detected
properties (methods/fields/whatever else) by hierarchy (from most concrete
to the "highest" parent). And the compiler provides already some safeguards.
Still all that doesn't solve the problem of colliding properties being
written by the user (via some custom ser. code).
But well... we can't always prevent people from doing stupid things :)
2015-04-20 19:11 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com>:
> 2015-04-20 19:05 GMT+02:00 Eugen Cepoi <cepoi.eugen_at_gmail.com>:
> >
> > 2015-04-19 19:44 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com>:
> >>
> >> Hi Martin
> >>
> >> for me it makes sense to support it by default with a flag like the
> >> one you proposed to switch it off (a bit off topic but do we have
> >> constants for these flags, something like Jsonb.I_JSON_COMPLIANCE?).
> >>
> >> UTF8 by default is quite mandatory IMO, must-ignore as well (already
> >> discussed IIRC). ISO8601 is the standard for dates of most of
> >> frameworks, big numbers need to be string whatever we do so finally
> >> open points from my window are:
> >>
> >> - byte data as base64: on johnzon we discussed it and I didn't want it
> >> cause it was far from Java - that said it is not a super common type
> >> so not sure it is that important
> >> - top level construct: don't recall the spec but I think primitives
> >> (string, numbers) can be supported as well. Jackson does it at least
> >> so +1 to not support this fail fast behavior
> >
> >
> > I don't think there is much value in being too restrictive, +1 for it.
> > I don't remember any discussion about accepting to deser. numbers as
> > strings, strings as numbers etc when possible, but it would be nice.
> >
> >>
> >> - no members with duplicate name: the only point I don't know.
> >
> >
> > This one is painful as it has an impact on performances (esp. if we want
> to
> > prevent user custom code to generate such output)... at the moment I
> don't
> > support it in Genson for this reason.
> >
>
> Can't we do it on the model (ie once for the whole application
> lifecycle)? I guess here we are lucky compared to JSON-P.
>
> >>
> >> Intellij Idea makes this kind of JON invalid. This is something we
> >> would need to be able to switch off but I think it makes sense to have
> >> it by default to detect wrong models.
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau
> >> http://www.tomitribe.com
> >> http://rmannibucau.wordpress.com
> >> https://github.com/rmannibucau
> >>
> >>
> >> 2015-04-18 19:53 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
> >> > Hi Experts,
> >> >
> >> >
> >> > JSON-B should provide support or some level of compliance with I-JSON
> >> > specification.
> >> >
> >> > https://tools.ietf.org/html/rfc7493
> >> >
> >> > There are several things to discuss.
> >> >
> >> > Should JSON-B support I-JSON by default? My proposal is to not support
> >> > all
> >> > the recommendations of I-JSON by default.
> >> >
> >> > If we agree on that, what specific parts of I-JSON should JSON-B
> provide
> >> > by
> >> > default?
> >> >
> >> >
> >> > Proposal of parts (of I-JSON) to support by JSON-B by default:
> >> >
> >> > Should be supported by default:
> >> > - Encoding and Characters (UTF-8 by default)
> >> > - Object constraints (no members with duplicate name)
> >> > - MUST-IGNORE policy - partial mapping
> >> > - Time and Date Handling - serialize accoring to I-JSON
> >> >
> >> > Should not be supported by default:
> >> > - Numbers - serialize big number(s) into string (and deser given
> strings
> >> > into number)
> >> > - Top-Level Constructs - fail fast when ser/deser something different
> >> > than
> >> > object/array as top-level JSON
> >> > - binary data encoded as a string in base64url
> >> >
> >> >
> >> > To support I-JSON fully in some case, I propose to provide I-JSON
> >> > compatibility mode available via config property.
> >> >
> >> > JsonbConfig config = new
> >> > JsonbConfig().setProperty("jsonb.i-json.compliance", true);
> >> > Jsonb jsonb = JsonbBuilder.create(config);
> >> >
> >> > Looking forward to your feedback.
> >> >
> >> > MartinV
> >
> >
>