2015-05-13 16:31 GMT+02:00 Eugen Cepoi <cepoi.eugen_at_gmail.com>:
>
>
> 2015-05-13 14:53 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
>>
>>
>>
>> On Wed, May 13, 2015 at 1:34 PM, Eugen Cepoi <cepoi.eugen_at_gmail.com>
>> wrote:
>>>
>>>
>>>
>>> 2015-05-13 8:40 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
>>>>
>>>> Hi Experts,
>>>>
>>>> we should get some conclusion to this discussion.
>>>>
>>>> I have the following notes:
>>>>
>>>> 1. Nillable, JsonbProperty, JsonbTransient
>>>>
>>>> I don't see any problem adding nillable attribute to JsonbProperty
>>>> annotation. The situation with JsonbTransient is different, because
>>>> transient field is effectively not a JsonbProperty. I think JsonbTransient
>>>> should stay as is.
>>>>
>>>>
>>>> Adding target Property to JsonbProperty makes sense.
>>>>
>>>> 2. Property Naming
>>>>
>>>>
>>>> I see concept of Mappers equivalent to JsonbAdapter (analogy to
>>>> XmlAdapter). It means that JsonbAdapter should see the context to be able to
>>>> do complex mapping between type and JSON fragment.
>>>
>>>
>>> What is the context to you? From memory there is no context in
>>> XmlAdapter. Also I think it could make sense to allow users to register
>>> Adapters directly to JsonB (using the builder or config) vs only via
>>> annotations.
>>>
>>
>>
>> Right now I don't know exactly what information JsonbAdapter needs, but
>> the idea behind context is that JsonbAdapter should be able to override as
>> much as possible behavior of default mapping.
>
>
> Ok I see, let's take each point one after the other. But before that, I
> think having a kind of easy to custom ser/de system is a good thing (esp for
> deser). So the idea of an adapter that converts one type to another sounds
> quite powerful to me. Because the user can for example translate it to a
> plain string or to some other complex structure that we know how to ser/de
> by default (a json object?).
> But in some situations as you mention the user might need contextual
> information (to be defined what this really is).
>
+1 for trivial adapters *by default*
>>
>> One option is to give access to JsonbConfig.
>
>
> So here the user would need access to the config used for the current Jsonb
> and perhaps also the jsonb instance.
> This sounds reasonable to me.
>
>>
>> It allows to change behavior when some property is set. The other option
>> is to have access to information what has already been processed.
>
>
> This one is ambigous. I think we don't know what it really means and what
> would be the use cases.
>
Should stay consistent whatever contextual means so can only be level
N-1 IMO cause level N (in progress) wouldnt guarantee anything.
>>
>> For example if there is dependency between objects in JSON.
>
>
> This means that the json or some action with side effects would be dynamic
> depending on the content. I think it should be avoided.
> At worst the user can provide an adapter for the object that contains those
> dependant properties and do there the complete ser/de.
> Sure not most easy to use, but it addresses a use case that is not frequent
> IMO.
>
> Note that the adapter stuff is different here from jsonb.toJson(...), so we
> would need something like jsonb.adapt(...), or jsonb.resolveAdapter(type)
> (so he can cache it and avoid repeted lookups?).
>
+1, do we integrate it with CDI when available (ie EE, not yet sure
about SE case)? +1 to do so.
>
>>
>> Another interesting option is possibility to skip some part of json,
>
>
> I think I don't get what you mean here :) Is it something like if
> (currentKeyInJson == "propertyIDontCare") jsonLowLevelStreamingApi.skip() ?
> If yes this means that we need to expose to the user the low level streaming
> API. In this case it is not how I see an adapter would work.
>
>>
>> or to change some behavior during processing of the JSON.
>
>
> Context means to me some other things too:
> - The name of the property being ser/de if any
> - The type of the property
> - The enclosing type
> - The annotaitons defined on the property if any
> - The type of the property
>
+ the annotations of the enclosing type (thinking to CDI you can
programmatically change them so we'd need getAnnotation(xxx) and
getClassAnnotation(xxx) or equivalent)
> This is best adressed by having a kind of contextual factory that would
> provide instances of Adapters configured with those things.
>
IMO adapters should be stateless but +1 for a Context factory
configurable on jsonb.
>>
>> But maybe there should be no context and to keep the concept of
>> JsonbAdapter simple in version 1.0.
>
>
> Having a Context object that wraps the current config and jsonb instance
> doesn't sound chocking to me. It's just a trade off between api simplicity
> and flexibility. I personally choosed to have a context similar to that in
> Genson, mainly to allow people to delegate the ser/de to the default
> converters.
>
> Having an adapter that converts one datastructure to another is easy to use
> but has the disadvatange of using more memory and perhaps is less "scalable"
> for large json.
>
> I think Inder could give us a better insight on this, as they had initially
> a Ser/De (=Adapter) in Gson and then added JsonAdapter (that deals with low
> level streaming api).
> I think that this could be acceptable to not expose the low level streaming
> api.
>
>>
>>
>>>>
>>>>
>>>> Composition of Mappings looks like an advanced feature and maybe it
>>>> should be postponed to future spec version.
>>>
>>>
>>> By composition of mappings do you think of allowing users to provide an
>>> Adapter/Mapper for some type that uses another registered adapters/mappers?
>>>
>>> For example I provide an PersonsAdapter<List<Person>> but inside I don't
>>> want to deal with the mapping of each entry and want to delegate to the
>>> default adapter of person.
>>>
>>>>
>>>> WDYT?
>>>>
>>>> 3. Property Order
>>>>
>>>> Case insensitive mapping is special, because it is not 1:1 mapping. To
>>>> make PropertyOrderStrategy simple, it should support only 1:1 mapping. In
>>>> that case PropertyOrderPolicy should not implement PropertyOrderStrategy. I
>>>> am not sure if there is a need to introduce Accessor class. In this case
>>>> simple String -> String mapping (accessor name -> JSON key) should work.
>>>> Implementations could provide some internal mechanism to call this function
>>>> only once per property.
>>>
>>>
>>> I guess you are talking about naming and mean PropertyNamingStrategy and
>>> PropertyNamingPolicy.
>>>
>> You are right, I was thining about different things at once and at the end
>> I have messed it into one point ...
>>
>>>
>>> Even if I like the names "strategy" and "policy" (who doesn't, this
>>> sounds pretty cool :)) I find them confusing when used together.
>>> I think both mean the same thing :)
>>>
>>
>> I'm not that good in inventing names :) If you have better names, it is
>> still possible to change that.
>
>
> Heh neither am I, that's pretty hard to do :) I'd vote for use one or the
> other but not both as they mean the same thing.
>
>>
>>
>>>
>>> To me there are two things with some common parts:
>>> - Resolve names (using Java Bean convetion/Annotations/Other)
>>> - Translate the string to another string
>>> (lower/upper/dashed/underscore/blabla)
>>>
>>
>> +1
>>
>>>
>>> The first one could deal directly with "properties" where the second one
>>> takes the resolved name and translates it.
>>> So here we have the choice of:
>>> - Have two separate concepts. One interface PropertyNameResolver that
>>> deals with properties or some abstraction. And a
>>> PropertyNamingStrategy/Policy interface that takes a string and returns
>>> another string (and provides the default impls as static attributes of the
>>> interface).
>>> - Or we consider that the name resolution is relatively fixed and
>>> handled inside the spec impl, thus we expose only the naming
>>> strategy/policy. Though I think this too is probably even more fixed...
>>> - Or we expose only the name resolution API
>>>
>>> No matter the choice, I'd be for providing default impls for all those
>>> inside the spec. There aren't many ways to implement a name resolution from
>>> java bean or annotations, neither to translate camel case to underscore...
>>>
>>
>>
>> Agree with default impls + two separate concepts.
>
>
> Ok so, we would have a PropertyNameResolver that is responsible of returning
> an Optional name (so they can be chained) for the input property and a
> PropertyNamingStrategy that would do the translation? If yes:
> - What form would take the property that is given to the name resolver? Std
> java Method/Field/Ctr/Method+Position or some wrapper?
wrapper to let user or (probably) framework change the metadata.
> - Would both be defined as an interface with a couple of impls provided
> inside the spec?
+1, a bit like bean validation which has default for all API, you can
get them thanks to getters and reset them with a custom impl
(potentially wrapping the default) before the runtime.
> - Need a method to register those in builder/jsonbconfig.
+1
>
>>
>>>>
>>>>
>>>> +1 for changing getPropertiesOrder to something immutable like
>>>> Collection/Iterable parameter.
>>>>
>>>> 4. JsonPointer support
>>>>
>>>> @JsonbProperty({"foo", "bar"}) vs @JsonbProperty("/foo/bar")
>>>>
>>>> This should be discussed in separate thread.
>>>>
>>>> 5. Null serialization policy
>>>>
>>>> Replacing enum with JsonbConfig options makes sense. User should be able
>>>> to implement custom null serialization policy for given type with the use of
>>>> JsonbAdapter (not proposed yet).
>>>
>>>
>>> I think it is nice to allow the users to not care about handling null
>>> input (when implementing their Adapter) and do it inside the spec. In this
>>> situation they would need a way to express "hey don't handle nulls for me" -
>>> or the inverse "please deal with nulls for me".
>>>
>>
>> It would be nice, but it could possibly complicate the contract and there
>> could be a lot of things (which can depend on each other) to specify.
>
>
> Depends. For example lets say I provide an adapter for DateTime. If the
> input date is null then I would just return null. Jsonb could do that for
> me. Same during deserializaiton when the value in the json is NULL.
>
> What do others think?
>
Sounds like a nice feature but I think by default null should be
handled by the framework. We can introduce a @Supports(nullValue =
true) or something like that on the adapter itself.
Other point: do we split the adapter in 2 to get a functional interface:
JsonbAdapter<A, B> {
A, apply(B);
}
this would allow to use lambda when registering adapters. Only change
it needs is to support serializer and deserializer property on the
adapter configuration (annotation on the field for instance). This
also allows to use the same object differently on read and write side
(getting base64url on one side and byte array on the other for
instance)
>>
>>>
>>> Eugen
>>>
>>>>
>>>>
>>>> MartinV
>>>>
>>>> On Wed, Apr 29, 2015 at 10:35 PM, Eugen Cepoi <cepoi.eugen_at_gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> 2015-04-29 22:18 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com>:
>>>>>>
>>>>>> 2015-04-29 21:54 GMT+02:00 Eugen Cepoi <cepoi.eugen_at_gmail.com>:
>>>>>> > I think JsonbProperty should accept Parameter as target. This would
>>>>>> > allow to
>>>>>> > use it on constructor parameters (and factory methods).
>>>>>> >
>>>>>> > About all the naming policy, I agre with Romain. We should have an
>>>>>> > interface
>>>>>> > that defines the naming strategy api (convert from one string to
>>>>>> > another or
>>>>>> > from a Method/Field/Param to a String) and provide impls as an enum
>>>>>> > for the
>>>>>> > actual policies.
>>>>>> >
>>>>>> > I don't think NullSerPolicy is useful. IMO it should be an option at
>>>>>> > the
>>>>>> > builder or jsonbconfig level and provide some way to the user to
>>>>>> > implement a
>>>>>> > custom strategy (so a kind of Adapter/Converter/Whatever where he
>>>>>> > has enough
>>>>>> > information to decide how he should ser/de).
>>>>>> >
>>>>>> > In PropertyOrderStrategy we give to the user control to a mutable
>>>>>> > structure
>>>>>> > the array of strings, perhaps we should provide just a
>>>>>> > collection/iterable
>>>>>> > or document that the user can or not modify the original structure.
>>>>>> > Also I
>>>>>> > am not sure there is enough information to sort things properly. For
>>>>>> > example
>>>>>> > the user doesn't know from which class the property comes (ex: A
>>>>>> > extends B,
>>>>>> > does it come from A or B).
>>>>>> >
>>>>>>
>>>>>> That is why a mapping API (class -> Map<String /* json key */,
>>>>>> Accessor> map(Class)) is nice but I agree it is less user friendly
>>>>>> since it mixed 3 concerns (naming, merging and accessibility). We can
>>>>>> of course provide helpers but not sure it is a good idea for a v1.0 of
>>>>>> the API.
>>>>>
>>>>>
>>>>> Mhh I don't like mixing so much things :)
>>>>>
>>>>> I don't know if its "the best" way, but in Genson I have one mechanism
>>>>> for selecting if a property (method/field/param) should be used in ser/de
>>>>> and another one that resolves the name (this is a bit different than a
>>>>> naming strategy where one would translate a string into another one). This
>>>>> allows one to choose what the name should be based on infos like
>>>>> annotations, declaring class, type etc. This is done per "property".
>>>>>
>>>>> Something similar doesn't prevent then having a "renaming" strategy
>>>>> that would take a string (without any other infos) and transform it to
>>>>> another string.
>>>>>
>>>>> The merging stuff is a bit more buried in the internal api as I didn't
>>>>> think people would need easy control over this.
>>>>>
>>>>>>
>>>>>>
>>>>>> > About Nillable, I don't care :) But following the same logic, what
>>>>>> > about
>>>>>> > JsonTransient?
>>>>>> >
>>>>>>
>>>>>> +1 for transient (as annotation or field of property one depending
>>>>>> what we decide here) is important to fully ignore a field.
>>>>>>
>>>>>> > For JsonPointer, Path & cie, jsonp will come with an impl of
>>>>>> > jsonpointer
>>>>>> > over the DOM model. This could make things easier... Also what's the
>>>>>> > advantage of @JsonbProperty({"foo", "bar"}) vs
>>>>>> > @JsonbProperty("/foo/bar") ?
>>>>>> > The sad thing is that I think we can't express something like:
>>>>>> >
>>>>>>
>>>>>> or even foo.bar? just the fact you can use all "single string" naming
>>>>>> as key and not path:
>>>>>
>>>>>
>>>>> Oh I didn't think about this. Naturally I would feel more comfortable
>>>>> to define a path "foo/bar" vs {"foo", "bar"}, but I don't have enough
>>>>> insight into this kind of usage to have a solid opinion :)
>>>>>
>>>>> Side note: I have been hesitant to add something similar in genson for
>>>>> some time, but initially I wanted to provide stuff that worked over streams
>>>>> and not DOM. In practice this gets tricky to implement (even more if you
>>>>> want to support immutable objects) and not flexible (once the stream has
>>>>> been consumed you can't extract properties from it anymore). So in the end
>>>>> relying on what has been done in jsonp could be more pragmatic...
>>>>>
>>>>>>
>>>>>>
>>>>>> { // Map
>>>>>> "/home/rmannibucau/Desktop": "5MB",
>>>>>> "/home/rmannibucau/dev": "65MB"
>>>>>> }
>>>>>>
>>>>>> which is valid to map to:
>>>>>>
>>>>>> public class MyFiles {
>>>>>> @JsonbProperty("/home/rmannibucau/Desktop")
>>>>>> private String desktop;
>>>>>>
>>>>>> @JsonbProperty("/home/rmannibucau/dev")
>>>>>> private String dev;
>>>>>> }
>>>>>>
>>>>>>
>>>>>> > @JsonProperty("/person/childrens/name")
>>>>>> > List<String> childrenNames;
>>>>>> >
>>>>>> > where the json would be
>>>>>> > {
>>>>>> > person {
>>>>>> > childrens: [ {...name: foo}, {...name: bar} ]
>>>>>> > }
>>>>>> > }
>>>>>> >
>>>>>> >
>>>>>> > I agree with Romain about the composition part. This can be pretty
>>>>>> > neat, not
>>>>>> > only for naming but also for property resolution.
>>>>>> >
>>>>>> >
>>>>>> > 2015-04-29 21:08 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com>:
>>>>>> >>
>>>>>> >>
>>>>>> >> Le 29 avr. 2015 19:18, "Martin Vojtek" <voytoo_at_gmail.com> a écrit :
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > On Wed, Apr 29, 2015 at 6:56 PM, Romain MB
>>>>>> >> > <rmannibucau_at_tomitribe.com>
>>>>>> >> > wrote:
>>>>>> >> >>
>>>>>> >> >> 2015-04-29 18:30 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
>>>>>> >> >> > Hi,
>>>>>> >> >> >
>>>>>> >> >> > ad 1) interface for PropertyNamingPolicy?
>>>>>> >> >> >
>>>>>> >> >> > I was experimenting with the idea of interface, but there is
>>>>>> >> >> > an open
>>>>>> >> >> > question how to design API to provide support also for the
>>>>>> >> >> > reverse
>>>>>> >> >> > mapping.
>>>>>> >> >> >
>>>>>> >> >> > For example, if I have case insensitive mapping, I need to
>>>>>> >> >> > know how
>>>>>> >> >> > to map
>>>>>> >> >> > from JSON key to field name (in efficient way). I have removed
>>>>>> >> >> > such
>>>>>> >> >> > an
>>>>>> >> >> > interface to see if there is a need for such customization
>>>>>> >> >> > (obviously
>>>>>> >> >> > there
>>>>>> >> >> > is :)).
>>>>>> >> >> >
>>>>>> >> >> > The alternative is to provide mechanism analogical to
>>>>>> >> >> > JAXBAdapter
>>>>>> >> >> > mechanism
>>>>>> >> >> > (or general mapper for given type).
>>>>>> >> >> >
>>>>>> >> >>
>>>>>> >> >> think we can do better than something called each time here. Why
>>>>>> >> >> not
>>>>>> >> >> just a Mapper? String map(Accessor)?
>>>>>> >> >>
>>>>>> >> >
>>>>>> >> > this is mapping from Accessor to JSON. This works in many cases
>>>>>> >> > (like
>>>>>> >> > 1:1), but what about other cases like case insensitive special
>>>>>> >> > case?
>>>>>> >> >
>>>>>> >>
>>>>>> >> I would expect to be able to compose them in my code:
>>>>>> >>
>>>>>> >> new MyMapping(DefaultMappings.LEXICOGRAPHIC,
>>>>>> >> DefaultMappings.CASE_INSENSITIVE);
>>>>>> >>
>>>>>> >> The impl being just a chain in this case but could also managed an
>>>>>> >> exclude
>>>>>> >> list to skip JPA state fields for instance - these fields are not
>>>>>> >> in user
>>>>>> >> code so cant be ignored by static code (annotations).
>>>>>> >>
>>>>>> >> > If we agree that this is enough and the special case will be
>>>>>> >> > handled by
>>>>>> >> > JsonbAdapter, that it is ok.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >>
>>>>>> >> >> > ad 2)
>>>>>> >> >> >
>>>>>> >> >> > The difference between JsonbNillable and JsonbProperty is also
>>>>>> >> >> > in
>>>>>> >> >> > scope. It
>>>>>> >> >> > makes sense to make JsonbNillable property to be available for
>>>>>> >> >> > Type/Package
>>>>>> >> >> > target.
>>>>>> >> >> >
>>>>>> >> >>
>>>>>> >> >> Makes sense but i would still add it in property and keep
>>>>>> >> >> @Nillable
>>>>>> >> >> for type and packages only.
>>>>>> >> >>
>>>>>> >> >
>>>>>> >> > Don't have strong opinion about this. What others think?
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >>
>>>>>> >> >> > ad 3)
>>>>>> >> >> >
>>>>>> >> >> > Maybe it makes sense to make it more general. What about JSON
>>>>>> >> >> > Pointer?
>>>>>> >> >> >
>>>>>> >> >>
>>>>>> >> >> can make sense but should stay simple/fluent cause it is super
>>>>>> >> >> common
>>>>>> >> >> (github/confluence/...). If you have some pseudo code we can
>>>>>> >> >> discuss
>>>>>> >> >> around I would be more than happy to dig into it.
>>>>>> >> >>
>>>>>> >> >
>>>>>> >> > I was thinking about similar functionality as MOXy XPath
>>>>>> >> > provides.
>>>>>> >> >
>>>>>> >> > https://wiki.eclipse.org/EclipseLink/Examples/MOXy/XPath
>>>>>> >> >
>>>>>> >> > JSON-B could support reasonable subset of JSON Pointer to map
>>>>>> >> > field
>>>>>> >> > (JavaBean property) to given node.
>>>>>> >> >
>>>>>> >>
>>>>>> >> Let s try it. Maybe needs its own thread then.
>>>>>> >>
>>>>>> >> >>
>>>>>> >> >> > ad ProertyOrderStrategy with enum)
>>>>>> >> >> >
>>>>>> >> >> > no problem to introduce enum. In that case I would also add
>>>>>> >> >> > LEXICOGRAPHICAL,
>>>>>> >> >> > which is default (and slightly different than ALPHABETICAL).
>>>>>> >> >> >
>>>>>> >> >> > MartinV
>>>>>> >> >> >
>>>>>> >> >> >
>>>>>> >> >> > On Wed, Apr 29, 2015 at 6:09 PM, Romain MB
>>>>>> >> >> > <rmannibucau_at_tomitribe.com>
>>>>>> >> >> > wrote:
>>>>>> >> >> >>
>>>>>> >> >> >> Hi
>>>>>> >> >> >>
>>>>>> >> >> >> @JsonbProperty is good to rename a property.
>>>>>> >> >> >>
>>>>>> >> >> >> However I don't like much PropertyNamingPolicy being an enum.
>>>>>> >> >> >> How do
>>>>>> >> >> >> I
>>>>>> >> >> >> do if I want to prefix everything with "mysuperapp_"? I would
>>>>>> >> >> >> use an
>>>>>> >> >> >> interface instead with default implementations (as constants
>>>>>> >> >> >> in
>>>>>> >> >> >> Jsonb
>>>>>> >> >> >> or in a DefaultPropertyNamingPolicies enum if you want). This
>>>>>> >> >> >> would
>>>>>> >> >> >> also be consistent with PropertyOrderStrategy (why not having
>>>>>> >> >> >> an
>>>>>> >> >> >> enum
>>>>>> >> >> >> with ALPHABETICAL, REFLECTION, REVERSE...)
>>>>>> >> >> >>
>>>>>> >> >> >> I think having nillable as an attribute of @JsonProperty is
>>>>>> >> >> >> maybe
>>>>>> >> >> >> better.
>>>>>> >> >> >>
>>>>>> >> >> >> Now the harder question. Suppose I have this json:
>>>>>> >> >> >>
>>>>>> >> >> >> {
>>>>>> >> >> >> "foo": {
>>>>>> >> >> >> "bar": "dummy"
>>>>>> >> >> >> }
>>>>>> >> >> >> }
>>>>>> >> >> >>
>>>>>> >> >> >> Can I map foo/bar to a field directly? I'm super tempted to
>>>>>> >> >> >> support
>>>>>> >> >> >> it. It means @JsonbProperty needs an array of string instead
>>>>>> >> >> >> a
>>>>>> >> >> >> simple
>>>>>> >> >> >> String:
>>>>>> >> >> >>
>>>>>> >> >> >> public class MyBinding {
>>>>>> >> >> >> @JsonbProperty({ "foo", "bar" })
>>>>>> >> >> >> private String bar;
>>>>>> >> >> >> }
>>>>>> >> >> >>
>>>>>> >> >> >> Side note: of course this doesn't prevent simple renaming
>>>>>> >> >> >> with the
>>>>>> >> >> >> same user API as today (speaking about the "look") thanks to
>>>>>> >> >> >> annotations properties:
>>>>>> >> >> >>
>>>>>> >> >> >> public class MyBinding {
>>>>>> >> >> >> @JsonbProperty("foo")
>>>>>> >> >> >> private Foo _foo;
>>>>>> >> >> >> }
>>>>>> >> >> >>
>>>>>> >> >> >> trying to summarize my feedback, here are the points I'd like
>>>>>> >> >> >> to
>>>>>> >> >> >> discuss:
>>>>>> >> >> >>
>>>>>> >> >> >> 1) interface for PropertyNamingPolicy?
>>>>>> >> >> >> 2) nillable in @JsonbProperty (means value() would have an
>>>>>> >> >> >> empty
>>>>>> >> >> >> default to keep a nice API in all cases)
>>>>>> >> >> >> 3) nested attribute support?
>>>>>> >> >> >>
>>>>>> >> >> >>
>>>>>> >> >> >> Romain Manni-Bucau
>>>>>> >> >> >> @rmannibucau
>>>>>> >> >> >> http://www.tomitribe.com
>>>>>> >> >> >> http://rmannibucau.wordpress.com
>>>>>> >> >> >> https://github.com/rmannibucau
>>>>>> >> >> >>
>>>>>> >> >> >>
>>>>>> >> >> >> 2015-04-29 17:36 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
>>>>>> >> >> >> > Hi Experts,
>>>>>> >> >> >> >
>>>>>> >> >> >> > I have pushed proposal regarding Customizing names.
>>>>>> >> >> >> >
>>>>>> >> >> >> > Short summary:
>>>>>> >> >> >> >
>>>>>> >> >> >> > introduce annotation and enum with most common naming
>>>>>> >> >> >> > policies.
>>>>>> >> >> >> >
>>>>>> >> >> >> > 1. use of javax.json.bind.annotation.JsonbProperty
>>>>>> >> >> >> > 2. using javax.json.bind.config.PropertyNamingPolicy
>>>>>> >> >> >> >
>>>>>> >> >> >> > JsonbProperty annotation is applicable to Field, getter or
>>>>>> >> >> >> > setter.
>>>>>> >> >> >> >
>>>>>> >> >> >> > PropertyNamingPolicy enum contains several different
>>>>>> >> >> >> > policies like
>>>>>> >> >> >> > IDENTITY,
>>>>>> >> >> >> > CASE_INSENSITIVE, LOWER_CASE_WITH_UNDERSCORE ...
>>>>>> >> >> >> >
>>>>>> >> >> >> > Details could be found in specification and in code (api +
>>>>>> >> >> >> > examples).
>>>>>> >> >> >> >
>>>>>> >> >> >> > MartinV
>>>>>> >> >> >> >
>>>>>> >> >> >> >
>>>>>> >> >> >
>>>>>> >> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >
>>>>>> >
>>>>>
>>>>>
>>>>
>>>
>>
>