2016-12-05 15:28 GMT+01:00 Dmitry Kornilov <dmitry.kornilov_at_oracle.com>:
> Hi Mark,
>
> Thanks for keeping us busy with real world use cases. ☺
>
> 1. I agree that making @JsonbProperty annotation work on non-public fields
> is a good idea. I think we should add it to the spec. If everybody agrees I
> (or Mark) can add a feature request for it in Jira.
>
> 2. I am not sure about the all fields visibility strategy. All popular
> binding frameworks (except Gson) are using the similar visibility strategy.
> So users are familiar with it already. Forcing vendors to implement ‘all
> fields’ visibility strategy looks too strict for me. But we can provide it
> in Yasson. If you would like to contribute, you are welcome. ☺
>
>
in johnzon we support it by default so makes already 2 mappers doing it so
I think it can be worth helping users to get back this behavior with a
oneliner
> Regards,
> Dmitry
>
> On 04/12/2016, 23:32, "Mark Struberg" <struberg_at_yahoo.de> wrote:
>
> Hi folks!
>
> I would like to give a bit feedback on using JSON-B in a real-world
> app.
>
> All works fine in JSON-B _if_ there are getters and setters.
>
> But it seems that JSON-B by spec ignores private fields if you don't
> have get/set for it (3.7.1) :(
> Here is my use case:
> ----
> public class SomeAttributeMap implements Serializable {
> private Map<String, DocAttribute> attributes = new HashMap();
>
> public DocAttributeMap putAttribute(String name, Object value) {
> attributes.put(name, new MyAttribute(value));
> return this;
> }
>
> public Object get(String name) {
> DocAttribute att = attributes.get(name);
> return att != null ? att.get() : null;
> }
> }
> ----
>
> The point is that 'attributes' is a private field. It is INTENTIONALLY
> private. I do not like to expose the internal details to the user!
>
> Creating a new SomeAttributeMap and put("x", 123); should result in
> the following JSON:{attributes=[{"x":1234}]}
> But what I get is {}...
>
> I also already tried @JsonbProperty, without success.
>
> And implementing an own PropertyVisibilityStrategy is possible but
> seriously overkill.
> I'd probably go that route IF there would be a default one for
> all_fields provided inside the JSON-B spec.
>
> Of course i can make it work, but what about the other 500k developers
> which are not that deep into it?
> Currently it is not as easily useable as JSON-B should be imo.
>
> a.) Why does adding a @JsonbProperty not have any impact? Is this a
> bug we missed in Johnzon or really spec defined?
> I mean, if someone *explicitly* annotates a field, why do we ignore
> it?
> From reading the spec it doesn't seem clear to me whether the
> paragraphs
> 4.1.2 javax.json.bind.annotation.JsonbProperty and
> 3.7.1 Scope and Field access strategy have a higher priority.
> Can anyone clarif this please?
>
> b.) Should I open a ticket for the default VisibilityStrategies for
> all_fields?
>
> A few other catches:
> c.)
> > Any instance passed to a deserialization operation must have a
> public or protected no-argument constructor.
> Shouldn't that just be: "... must have a no-argument constructor." ?
> Why does it need to be public or protected? Technically this
> restriction doesn't appear to make much sense.
> JSON-B does not do any subclassing, so i could even be a private
> default ct.
> If you say you need subclassing then probably '.. must have a
> non-private no-arg constructor.'
> Can someone please shed a light on this decision?
>
> txs and LieGrue,
> strub
>
> PS: Dmitry, sorry to disturb you. Just adding you as I'm not sure who
> moderates this list.
>
>
>
>
>
>