Hi Dmitry, Romain!
As far as I understood it is not even an impl change. JSON-B implementations _already_ have to support @JsonVisibility.
What I propose is enhancing the already existing interface in the spec API in the following way (or similar):
public interface PropertyVisibilityStrategy {
boolean isVisible(Field field);
boolean isVisible(Method method);
class VisibleAll implements PropertyVisibilityStrategy {
@Override
public boolean isVisible(Field field) {
return true;
}
@Override
public boolean isVisible(Method method) {
return true;
}
}
}
and probably
class VisibleAllFields which returns true for all fields but false for all methods. Something like that. Surely needs a bit brainstorming about what is most useful.
My intention is to prevent having that code in each and every single customer project again and again and again ;)
Oh and imo no need to change any impl, it's just the API which would get this simple default impl.
Wdyt?
LieGrue,
strub
> Am 05.12.2016 um 15:30 schrieb Romain Manni-Bucau <rmannibucau_at_tomitribe.com>:
>
>
> 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.
>
>
>
>
>
>