Better json through jackson
Adam Young
ayoung at redhat.com
Mon May 17 13:34:02 UTC 2010
If we do move to Jackson, please do so completely, so we can remove the
jettison dependency from the Build. Jettison is onerous to build, as it
requires a lot of things that it really shouldn't (IIRC, I built a ALOT
of packages).
Jackson has a really wierd naming scheme for packages: it appends the
license to the package name, something that is going against the Fedora
rules. It makes it a bit nicer for the Maven/buildr developer to
specify which license they want, but since there should be no issue with
using a lgpl library, it seems really unnecessary. Anyway, you'll be
dealing with this as part of getting Jackson rpms into Fedora if You
want Candlepin in Fedora.
On 05/17/2010 09:22 AM, Jesus M. Rodriguez wrote:
> On Mon, May 17, 2010 at 8:44 AM, James Bowes<jbowes at redhat.com> wrote:
>
>> All:
>>
>> I've pushed out a new branch for some fiddling I did on Friday night to
>> move from jettison for json reading/writing to jackson. IMO jackson
>> creates much nicer json. Here's what a consumer looks like:
>>
>> == OLD ==
>>
>> {"consumer" : {
>> "name" : "my consumer",
>> "type" : {"label" : "system" }
>> }
>> }
>>
>> == NEW ==
>>
>> {"name" : "my consumer",
>> "type" : "system"}
>>
>>
> How does it handle lists and child objects? For example does a list appear with
> a name:
>
> {"name":"my consumer",
> "owners":[{"name":"foo"}, {"name":"bar"}]
> }
>
> OR without a name:
> {"name":"my consumer",
> [{"name":"foo"}, {"name":"bar"}]
> }
>
>
>> Through nicer json, we get nicer client code (fewer redundant
>> variable/key names).
>>
>> Another cool think about jackson is it can generate json schema, which
>> I've hooked up in a few cases to the ApiCrawler.
>>
>> Before bringing this into master, I'd like to:
>> * make sure the java client speaks new json
>> * come up with a convention for variable names in json. I'd like to do:
>> endDate => end_date, as I think the underscore looks more jsonic.
>> enforce this convention.
>>
> +1 to _ :)
>
>
>> * Create our own json reader/writer so we can configure jacksons
>> settings for:
>> * Use "YYYY-MM-DDTHH:MM:SS-04:00" for datetime, rather than seconds
>> since the epoch
>>
> +1 we want to stick with the standard ISO8601 format.
>
>
>> * allow a configurable toggle for json pretty printing (great for
>> debugging)
>>
> +1
>
>
>> * Have the hooks in place for input validation (do after merge)
>> * Check for any concessions we made with jettison re base64 encoding or
>> int to string conversion, and elimnate them.
>> * consider dropping xml support, or consider using jaxb annotations for
>> jackson.
>>
> That was my next question, what happens to XML support. Today we have
> the option of supporting both XML and JSON simply based on the client's
> accept header. But to be honest I don't think we have even tested the XML
> at all. Plus there are many REST apis which only support JSON.
> I'm ok with dropping XML support.
>
>
>> I've also got patches for the python code locally, for when we switch.
>>
>> Comments?
>>
> Did you figure out the object graph serialization problem with jackson? the
> one where it just starts going down the entire graph. /me assumes you did
> but never hurts to ask :D
>
> Great work! Thanks for diving into this.
>
> jesus
> _______________________________________________
> candlepin mailing list
> candlepin at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin
>
More information about the candlepin
mailing list