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...
> 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?
> 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.
>
>
> 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
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>