8:34 a.m.
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(a)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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin