You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@johnzon.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2016/08/26 08:16:38 UTC
Serialization handling
Hi guys,
fixed https://issues.apache.org/jira/browse/JOHNZON-94 but wonder if we
should keep it, add a flag or just revert it.
In short to make the JsonValue serializable we hurt the fact the API
JsonValue (TRUE, FALSE, NULL) are not serializable. I worked around it
copying these 2 values in serializable versions but it means jsonvalue ==
JsonValue.TRUE would now fail as well as JsonValue.TRUE.equals(jsonvalue)
but jsonvalue.equals(JsonValue.TRUE) works. Since there is the
getValueType() which can be used as a reference I don't think it is a big
deal but would like to hear from you cause this sounds like a potential
drawback.
So here are the options:
1- just revert and WONTFIX the issue
2- keep it like that since this is not a big deal and more on the bad
practise side
3- fix geronimo API and ignore RI api case
4- add a flag to use or not the serializable copy of these values
5- other?
I'm happy with 2, 3, and 4 (and 5 ;))
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
Re: Serialization handling
Posted by Romain Manni-Bucau <rm...@gmail.com>.
went with 5 (updated https://issues.apache.org/jira/browse/JOHNZON-94)
feel free to hack/update
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-08-26 12:19 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> So do we go with 5 which can work today with some perf degradation?
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-08-26 12:10 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
>
>>
>> 2016-08-26 12:08 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
>>
>>> Folks, I already proposed Serialization for JSON-P 1.1 for JsonPatch and
>>> JsonPointer. I think the JsonValue.TRUE and FALSE also _must_ be made
>>> serializable in the spec.
>>>
>>> Or even make JsonValue extends Serializable and add a TCK test to check
>>> it.
>>>
>>> I will create an explicit ticket in the spec for this.
>>>
>>> Of course for JSON-P-1.0 we are pretty much out of luck.
>>> Introducing the wrapper type would defeat the whole purpose of
>>> JsonValue.NULL etc as == wont work anymore :(
>>>
>>> This is really not (only) a Johnzon problem but a spec issue :(
>>>
>>>
>> Right but what do we do? :)
>>
>> Also it is written nowhere == should work even if it is tempting.
>>
>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
>>>
>>> > On Friday, 26 August 2016, 10:40, Romain Manni-Bucau <
>>> rmannibucau@gmail.com> wrote:
>>> > > 2016-08-26 10:36 GMT+02:00 Reinhard Sandtner
>>> > <re...@gmail.com>:
>>> >
>>> >> Hey,
>>> >>
>>> >> i’m +1 with 4 and fix/discuss it in JSON_P_1.1
>>> >> so we can remove the flag once it got fixed in the spec or if it
>>> will not
>>> >> get fixed the user must take care of the == and equals()
>>> >>
>>> >>
>>> > spec wise it is already the case, excepted for enum nothing in the spec
>>> > says == should work
>>> >
>>> >
>>> >> 3 would be an option but i personally don’t like it because we say
>>> 'It
>>> >> fully implements the JSON-P_1.0 specification (JSR-353)‘
>>> >>
>>> >>
>>> > Well if we do then we'll not pass the signature check (I'm ok with that
>>> > but
>>> > means we can't get the "compliant" stamp)
>>> >
>>> >
>>> >> -1 for 2 even if we document it really good and clear this can be a
>>> bug
>>> >> you ran which is really (of course easy to fix) but hard to find
>>> >> -1 for 1 too
>>> >>
>>> >
>>> > Forgot one option:
>>> >
>>> > 5. add a writereplace/readResolve for all our instances using
>>> > toString/parsing as serialization process and ignore primitives
>>> (true/null)
>>> > direct handling. Ie if the user reads a primitive - quite unlikely to
>>> keep
>>> > the JsonValue there - then we don't handle it and the user should do it
>>> > himself but if we read an object/array then it should be transparent
>>> >
>>> >
>>> >
>>> >>
>>> >> lg
>>> >> reini
>>> >>
>>> >>
>>> >> > Am 26.08.2016 um 10:16 schrieb Romain Manni-Bucau
>>> > <rmannibucau@gmail.com
>>> >> >:
>>> >> >
>>> >> > Hi guys,
>>> >> >
>>> >> > fixed https://issues.apache.org/jira/browse/JOHNZON-94 but wonder
>>> if
>>> > we
>>> >> > should keep it, add a flag or just revert it.
>>> >> >
>>> >> > In short to make the JsonValue serializable we hurt the fact the
>>> API
>>> >> > JsonValue (TRUE, FALSE, NULL) are not serializable. I worked
>>> around it
>>> >> > copying these 2 values in serializable versions but it means
>>> jsonvalue
>>> > ==
>>> >> > JsonValue.TRUE would now fail as well as JsonValue.TRUE.equals(
>>> >> jsonvalue)
>>> >> > but jsonvalue.equals(JsonValue.TRUE) works. Since there is the
>>> >> > getValueType() which can be used as a reference I don't think it
>>> > is a big
>>> >> > deal but would like to hear from you cause this sounds like a
>>> > potential
>>> >> > drawback.
>>> >> >
>>> >> > So here are the options:
>>> >> >
>>> >> > 1- just revert and WONTFIX the issue
>>> >> > 2- keep it like that since this is not a big deal and more on the
>>> bad
>>> >> > practise side
>>> >> > 3- fix geronimo API and ignore RI api case
>>> >> > 4- add a flag to use or not the serializable copy of these values
>>> >> > 5- other?
>>> >> >
>>> >> > I'm happy with 2, 3, and 4 (and 5 ;))
>>> >> >
>>> >> > Romain Manni-Bucau
>>> >> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>> >> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
>>> >> > <http://rmannibucau.wordpress.com> | Github
>>> > <https://github.com/
>>> >> rmannibucau> |
>>> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>> >> > <http://www.tomitribe.com> | JavaEE Factory
>>> >> > <https://javaeefactory-rmannibucau.rhcloud.com>
>>> >>
>>> >>
>>> >
>>>
>>
>>
>
Re: Serialization handling
Posted by Romain Manni-Bucau <rm...@gmail.com>.
So do we go with 5 which can work today with some perf degradation?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-08-26 12:10 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
>
> 2016-08-26 12:08 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
>
>> Folks, I already proposed Serialization for JSON-P 1.1 for JsonPatch and
>> JsonPointer. I think the JsonValue.TRUE and FALSE also _must_ be made
>> serializable in the spec.
>>
>> Or even make JsonValue extends Serializable and add a TCK test to check
>> it.
>>
>> I will create an explicit ticket in the spec for this.
>>
>> Of course for JSON-P-1.0 we are pretty much out of luck.
>> Introducing the wrapper type would defeat the whole purpose of
>> JsonValue.NULL etc as == wont work anymore :(
>>
>> This is really not (only) a Johnzon problem but a spec issue :(
>>
>>
> Right but what do we do? :)
>
> Also it is written nowhere == should work even if it is tempting.
>
>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>> > On Friday, 26 August 2016, 10:40, Romain Manni-Bucau <
>> rmannibucau@gmail.com> wrote:
>> > > 2016-08-26 10:36 GMT+02:00 Reinhard Sandtner
>> > <re...@gmail.com>:
>> >
>> >> Hey,
>> >>
>> >> i’m +1 with 4 and fix/discuss it in JSON_P_1.1
>> >> so we can remove the flag once it got fixed in the spec or if it will
>> not
>> >> get fixed the user must take care of the == and equals()
>> >>
>> >>
>> > spec wise it is already the case, excepted for enum nothing in the spec
>> > says == should work
>> >
>> >
>> >> 3 would be an option but i personally don’t like it because we say 'It
>> >> fully implements the JSON-P_1.0 specification (JSR-353)‘
>> >>
>> >>
>> > Well if we do then we'll not pass the signature check (I'm ok with that
>> > but
>> > means we can't get the "compliant" stamp)
>> >
>> >
>> >> -1 for 2 even if we document it really good and clear this can be a
>> bug
>> >> you ran which is really (of course easy to fix) but hard to find
>> >> -1 for 1 too
>> >>
>> >
>> > Forgot one option:
>> >
>> > 5. add a writereplace/readResolve for all our instances using
>> > toString/parsing as serialization process and ignore primitives
>> (true/null)
>> > direct handling. Ie if the user reads a primitive - quite unlikely to
>> keep
>> > the JsonValue there - then we don't handle it and the user should do it
>> > himself but if we read an object/array then it should be transparent
>> >
>> >
>> >
>> >>
>> >> lg
>> >> reini
>> >>
>> >>
>> >> > Am 26.08.2016 um 10:16 schrieb Romain Manni-Bucau
>> > <rmannibucau@gmail.com
>> >> >:
>> >> >
>> >> > Hi guys,
>> >> >
>> >> > fixed https://issues.apache.org/jira/browse/JOHNZON-94 but wonder
>> if
>> > we
>> >> > should keep it, add a flag or just revert it.
>> >> >
>> >> > In short to make the JsonValue serializable we hurt the fact the API
>> >> > JsonValue (TRUE, FALSE, NULL) are not serializable. I worked around
>> it
>> >> > copying these 2 values in serializable versions but it means
>> jsonvalue
>> > ==
>> >> > JsonValue.TRUE would now fail as well as JsonValue.TRUE.equals(
>> >> jsonvalue)
>> >> > but jsonvalue.equals(JsonValue.TRUE) works. Since there is the
>> >> > getValueType() which can be used as a reference I don't think it
>> > is a big
>> >> > deal but would like to hear from you cause this sounds like a
>> > potential
>> >> > drawback.
>> >> >
>> >> > So here are the options:
>> >> >
>> >> > 1- just revert and WONTFIX the issue
>> >> > 2- keep it like that since this is not a big deal and more on the
>> bad
>> >> > practise side
>> >> > 3- fix geronimo API and ignore RI api case
>> >> > 4- add a flag to use or not the serializable copy of these values
>> >> > 5- other?
>> >> >
>> >> > I'm happy with 2, 3, and 4 (and 5 ;))
>> >> >
>> >> > Romain Manni-Bucau
>> >> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> >> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
>> >> > <http://rmannibucau.wordpress.com> | Github
>> > <https://github.com/
>> >> rmannibucau> |
>> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> >> > <http://www.tomitribe.com> | JavaEE Factory
>> >> > <https://javaeefactory-rmannibucau.rhcloud.com>
>> >>
>> >>
>> >
>>
>
>
Re: Serialization handling
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2016-08-26 12:08 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
> Folks, I already proposed Serialization for JSON-P 1.1 for JsonPatch and
> JsonPointer. I think the JsonValue.TRUE and FALSE also _must_ be made
> serializable in the spec.
>
> Or even make JsonValue extends Serializable and add a TCK test to check it.
>
> I will create an explicit ticket in the spec for this.
>
> Of course for JSON-P-1.0 we are pretty much out of luck.
> Introducing the wrapper type would defeat the whole purpose of
> JsonValue.NULL etc as == wont work anymore :(
>
> This is really not (only) a Johnzon problem but a spec issue :(
>
>
Right but what do we do? :)
Also it is written nowhere == should work even if it is tempting.
>
> LieGrue,
> strub
>
>
>
>
>
> > On Friday, 26 August 2016, 10:40, Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
> > > 2016-08-26 10:36 GMT+02:00 Reinhard Sandtner
> > <re...@gmail.com>:
> >
> >> Hey,
> >>
> >> i’m +1 with 4 and fix/discuss it in JSON_P_1.1
> >> so we can remove the flag once it got fixed in the spec or if it will
> not
> >> get fixed the user must take care of the == and equals()
> >>
> >>
> > spec wise it is already the case, excepted for enum nothing in the spec
> > says == should work
> >
> >
> >> 3 would be an option but i personally don’t like it because we say 'It
> >> fully implements the JSON-P_1.0 specification (JSR-353)‘
> >>
> >>
> > Well if we do then we'll not pass the signature check (I'm ok with that
> > but
> > means we can't get the "compliant" stamp)
> >
> >
> >> -1 for 2 even if we document it really good and clear this can be a bug
> >> you ran which is really (of course easy to fix) but hard to find
> >> -1 for 1 too
> >>
> >
> > Forgot one option:
> >
> > 5. add a writereplace/readResolve for all our instances using
> > toString/parsing as serialization process and ignore primitives
> (true/null)
> > direct handling. Ie if the user reads a primitive - quite unlikely to
> keep
> > the JsonValue there - then we don't handle it and the user should do it
> > himself but if we read an object/array then it should be transparent
> >
> >
> >
> >>
> >> lg
> >> reini
> >>
> >>
> >> > Am 26.08.2016 um 10:16 schrieb Romain Manni-Bucau
> > <rmannibucau@gmail.com
> >> >:
> >> >
> >> > Hi guys,
> >> >
> >> > fixed https://issues.apache.org/jira/browse/JOHNZON-94 but wonder if
> > we
> >> > should keep it, add a flag or just revert it.
> >> >
> >> > In short to make the JsonValue serializable we hurt the fact the API
> >> > JsonValue (TRUE, FALSE, NULL) are not serializable. I worked around
> it
> >> > copying these 2 values in serializable versions but it means
> jsonvalue
> > ==
> >> > JsonValue.TRUE would now fail as well as JsonValue.TRUE.equals(
> >> jsonvalue)
> >> > but jsonvalue.equals(JsonValue.TRUE) works. Since there is the
> >> > getValueType() which can be used as a reference I don't think it
> > is a big
> >> > deal but would like to hear from you cause this sounds like a
> > potential
> >> > drawback.
> >> >
> >> > So here are the options:
> >> >
> >> > 1- just revert and WONTFIX the issue
> >> > 2- keep it like that since this is not a big deal and more on the bad
> >> > practise side
> >> > 3- fix geronimo API and ignore RI api case
> >> > 4- add a flag to use or not the serializable copy of these values
> >> > 5- other?
> >> >
> >> > I'm happy with 2, 3, and 4 (and 5 ;))
> >> >
> >> > Romain Manni-Bucau
> >> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> >> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> >> > <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/
> >> rmannibucau> |
> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >> > <http://www.tomitribe.com> | JavaEE Factory
> >> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >>
> >>
> >
>
Re: Serialization handling
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Folks, I already proposed Serialization for JSON-P 1.1 for JsonPatch and JsonPointer. I think the JsonValue.TRUE and FALSE also _must_ be made serializable in the spec.
Or even make JsonValue extends Serializable and add a TCK test to check it.
I will create an explicit ticket in the spec for this.
Of course for JSON-P-1.0 we are pretty much out of luck.
Introducing the wrapper type would defeat the whole purpose of JsonValue.NULL etc as == wont work anymore :(
This is really not (only) a Johnzon problem but a spec issue :(
LieGrue,
strub
> On Friday, 26 August 2016, 10:40, Romain Manni-Bucau <rm...@gmail.com> wrote:
> > 2016-08-26 10:36 GMT+02:00 Reinhard Sandtner
> <re...@gmail.com>:
>
>> Hey,
>>
>> i’m +1 with 4 and fix/discuss it in JSON_P_1.1
>> so we can remove the flag once it got fixed in the spec or if it will not
>> get fixed the user must take care of the == and equals()
>>
>>
> spec wise it is already the case, excepted for enum nothing in the spec
> says == should work
>
>
>> 3 would be an option but i personally don’t like it because we say 'It
>> fully implements the JSON-P_1.0 specification (JSR-353)‘
>>
>>
> Well if we do then we'll not pass the signature check (I'm ok with that
> but
> means we can't get the "compliant" stamp)
>
>
>> -1 for 2 even if we document it really good and clear this can be a bug
>> you ran which is really (of course easy to fix) but hard to find
>> -1 for 1 too
>>
>
> Forgot one option:
>
> 5. add a writereplace/readResolve for all our instances using
> toString/parsing as serialization process and ignore primitives (true/null)
> direct handling. Ie if the user reads a primitive - quite unlikely to keep
> the JsonValue there - then we don't handle it and the user should do it
> himself but if we read an object/array then it should be transparent
>
>
>
>>
>> lg
>> reini
>>
>>
>> > Am 26.08.2016 um 10:16 schrieb Romain Manni-Bucau
> <rmannibucau@gmail.com
>> >:
>> >
>> > Hi guys,
>> >
>> > fixed https://issues.apache.org/jira/browse/JOHNZON-94 but wonder if
> we
>> > should keep it, add a flag or just revert it.
>> >
>> > In short to make the JsonValue serializable we hurt the fact the API
>> > JsonValue (TRUE, FALSE, NULL) are not serializable. I worked around it
>> > copying these 2 values in serializable versions but it means jsonvalue
> ==
>> > JsonValue.TRUE would now fail as well as JsonValue.TRUE.equals(
>> jsonvalue)
>> > but jsonvalue.equals(JsonValue.TRUE) works. Since there is the
>> > getValueType() which can be used as a reference I don't think it
> is a big
>> > deal but would like to hear from you cause this sounds like a
> potential
>> > drawback.
>> >
>> > So here are the options:
>> >
>> > 1- just revert and WONTFIX the issue
>> > 2- keep it like that since this is not a big deal and more on the bad
>> > practise side
>> > 3- fix geronimo API and ignore RI api case
>> > 4- add a flag to use or not the serializable copy of these values
>> > 5- other?
>> >
>> > I'm happy with 2, 3, and 4 (and 5 ;))
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
>> > <http://rmannibucau.wordpress.com> | Github
> <https://github.com/
>> rmannibucau> |
>> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> > <http://www.tomitribe.com> | JavaEE Factory
>> > <https://javaeefactory-rmannibucau.rhcloud.com>
>>
>>
>
Re: Serialization handling
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2016-08-26 10:36 GMT+02:00 Reinhard Sandtner <re...@gmail.com>:
> Hey,
>
> i’m +1 with 4 and fix/discuss it in JSON_P_1.1
> so we can remove the flag once it got fixed in the spec or if it will not
> get fixed the user must take care of the == and equals()
>
>
spec wise it is already the case, excepted for enum nothing in the spec
says == should work
> 3 would be an option but i personally don’t like it because we say 'It
> fully implements the JSON-P_1.0 specification (JSR-353)‘
>
>
Well if we do then we'll not pass the signature check (I'm ok with that but
means we can't get the "compliant" stamp)
> -1 for 2 even if we document it really good and clear this can be a bug
> you ran which is really (of course easy to fix) but hard to find
> -1 for 1 too
>
Forgot one option:
5. add a writereplace/readResolve for all our instances using
toString/parsing as serialization process and ignore primitives (true/null)
direct handling. Ie if the user reads a primitive - quite unlikely to keep
the JsonValue there - then we don't handle it and the user should do it
himself but if we read an object/array then it should be transparent
>
> lg
> reini
>
>
> > Am 26.08.2016 um 10:16 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > Hi guys,
> >
> > fixed https://issues.apache.org/jira/browse/JOHNZON-94 but wonder if we
> > should keep it, add a flag or just revert it.
> >
> > In short to make the JsonValue serializable we hurt the fact the API
> > JsonValue (TRUE, FALSE, NULL) are not serializable. I worked around it
> > copying these 2 values in serializable versions but it means jsonvalue ==
> > JsonValue.TRUE would now fail as well as JsonValue.TRUE.equals(
> jsonvalue)
> > but jsonvalue.equals(JsonValue.TRUE) works. Since there is the
> > getValueType() which can be used as a reference I don't think it is a big
> > deal but would like to hear from you cause this sounds like a potential
> > drawback.
> >
> > So here are the options:
> >
> > 1- just revert and WONTFIX the issue
> > 2- keep it like that since this is not a big deal and more on the bad
> > practise side
> > 3- fix geronimo API and ignore RI api case
> > 4- add a flag to use or not the serializable copy of these values
> > 5- other?
> >
> > I'm happy with 2, 3, and 4 (and 5 ;))
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
>
>
Re: Serialization handling
Posted by Reinhard Sandtner <re...@gmail.com>.
Hey,
i’m +1 with 4 and fix/discuss it in JSON_P_1.1
so we can remove the flag once it got fixed in the spec or if it will not get fixed the user must take care of the == and equals()
3 would be an option but i personally don’t like it because we say 'It fully implements the JSON-P_1.0 specification (JSR-353)‘
-1 for 2 even if we document it really good and clear this can be a bug you ran which is really (of course easy to fix) but hard to find
-1 for 1 too
lg
reini
> Am 26.08.2016 um 10:16 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> Hi guys,
>
> fixed https://issues.apache.org/jira/browse/JOHNZON-94 but wonder if we
> should keep it, add a flag or just revert it.
>
> In short to make the JsonValue serializable we hurt the fact the API
> JsonValue (TRUE, FALSE, NULL) are not serializable. I worked around it
> copying these 2 values in serializable versions but it means jsonvalue ==
> JsonValue.TRUE would now fail as well as JsonValue.TRUE.equals(jsonvalue)
> but jsonvalue.equals(JsonValue.TRUE) works. Since there is the
> getValueType() which can be used as a reference I don't think it is a big
> deal but would like to hear from you cause this sounds like a potential
> drawback.
>
> So here are the options:
>
> 1- just revert and WONTFIX the issue
> 2- keep it like that since this is not a big deal and more on the bad
> practise side
> 3- fix geronimo API and ignore RI api case
> 4- add a flag to use or not the serializable copy of these values
> 5- other?
>
> I'm happy with 2, 3, and 4 (and 5 ;))
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>