2015-04-20 22:22 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com>:
> 2015-04-20 20:35 GMT+02:00 Eugen Cepoi <cepoi.eugen_at_gmail.com>:
> >
> >
> > 2015-04-20 19:40 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com>:
> >>
> >> I understand, that's where we don't see it the exact same way. You
> >> merge it by name where I would merge it by java model with standard
> >> order. So basically I'd do a reduce (java) then validation (json side
> >> if we can call it this way).
> >
> >
> > Ah ok, so you would only merge by the name of the field or method.
> > This is viable but would force to make a distinction between resolved
> name
> > using java bean convention and other naming strategies (annotation,
> custom
> > user strategy etc). For Genson I prefered to have only one name
> resolution
> > system and use it always the same way, there are less "rules" involved
> > making things easier to understand.
> > But it can have some advantages to make the distinction...
> >
>
> yes basically all is resolved on java side then we can check
> @JsonProperty (supposed it is the right name) to check the name to
> use, if not present use the one deduced from java. Merge is less
> aggressive and allows few validations.
>
So by java side resolution you mean we use the same strategy as java?
This means that fields/methods from class A overrides what matches in its
super class.
In short:
1) reduce accessors/mutators by name and definition order in class hierarchy
2) apply any "renaming" strategy on the result of 1)
3) reduce the result of 2) using the same strategy as in 1)
If yes then I think we can simplify things by directly applying the
renaming and then doing a single "reduce" that overrides or throws an
exception.
Allowing to override has some advantages, for example you can extend a
class of which you don't have control and redefine how some property would
be ser/de - a quick solution vs implementing a full custom ser/de for that
enclosing type.
Would be interesting to know what others think.
> >>
> >> Doesnt impact performances.
> >
> >
> > True, doing it on the resolved java model (with renamed or not
> properties)
> > doesn't change the perfs.
> >
> >>
> >>
> >> Now the real question is: do we gain anything compared to what you
> >> propose ie ensuring we don't have conflicts. I still think it can make
> >> sense to validate there isn't a "model conflict". Implicit merging can
> >> be hard to debug from my experience.
> >
> >
> > So you would throw an exception for example if there are two properties
> with
> > the same name in a class and its parent?
> > If yes then we should make sure of the "rules" applied as there might be
> > ambiguous situations. How do you think we should distinguish valid from
> > invalid conflicts for renamed properties?
> >
>
> We can have rules like "an overriden method is not a conflict if a
> field is not hiding parent one" etc but we can also do like in bean
> validation and define inheritance API. A bit more verbose but clearer
> IMO (+ does it really happen often in real life?). Something like
> @OverrideJsonAttribute("parentName").
>
>
Having a specific API for overriding looks overkill, I'd prefer just to
agree on a good default behaviour.
> >>
> >> That said if we ensure the
> >> framework logs it properly (level = warn + logger name =
> >> javax.json.something) then it would work for me as well.
> >
> >
> > I would prefer to just throw an exception or consider it as valid rather
> > than log a warn.
> >
>
> Works, just want it to be visible and not too implicit.
>
> >>
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau
> >> http://www.tomitribe.com
> >> http://rmannibucau.wordpress.com
> >> https://github.com/rmannibucau
> >>
> >>
> >> 2015-04-20 19:34 GMT+02:00 Eugen Cepoi <cepoi.eugen_at_gmail.com>:
> >> >
> >> >
> >> > 2015-04-20 19:28 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com>:
> >> >>
> >> >> well not supporting the validation for custom serialization code
> >> >> doesnt sound like a big issue for me but it doesn't prevent to
> >> >> validate the model. I didn't speak of the merging but for instance 2
> >> >> different methods/fields decorated with @JsonProperty(name="foo").
> >> >
> >> >
> >> > Yes I was including renamed properties in that and by merging I was
> >> > meaning
> >> > take N properties (field/method/ctr) and reduce it to one (how you
> >> > achieve
> >> > it is up to the impl).
> >> > To me renamed or original name is the same, as I first resolve the
> names
> >> > and
> >> > then do all the selection/merging stuff.
> >> > Amongst others, this allows to override in subclasses things from
> parent
> >> > classes - by using the same name.
> >> >
> >> >>
> >> >>
> >> >> For me just doing it already matches the intention behind I-JSON.
> >> >>
> >> >> Romain Manni-Bucau
> >> >> @rmannibucau
> >> >> http://www.tomitribe.com
> >> >> http://rmannibucau.wordpress.com
> >> >> https://github.com/rmannibucau
> >> >>
> >> >>
> >> >> 2015-04-20 19:24 GMT+02:00 Eugen Cepoi <cepoi.eugen_at_gmail.com>:
> >> >> > 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
> >> >> >> >
> >> >> >> >
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>