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