Using Jackson DataBind for JSON Serialization/Deserialization

[David Fuelling]

Hello, 

I prefer to *not* to use the @Key pattern in my POJO's, but would still like to use Jackson2 for Serialization/Deserialization to/from JSON, ideally using jackson-data-bind (https://github.com/FasterXML/jackson-databind)

Is there an easy way to enable this?  I've figured out a way to make this work, but it but I've had to create a custom version of JsonFactory, a custom JsonObjectParser, and am having to use a custom version of JsonHttpContent that doesn't look for the @Key annotation when generating JSON.  Unfortunately, my solution feels a bit clunky, and I'm not entirely sure if what I've done is ideal or even advisable.  

I suppose something like issue #25 would seem to provide a proper framework for what I'm trying to do.  Any thoughts here?

Thanks!

david

[David Bullock]

The convenience afforded by @Key is one of the main attractions of using this library.  Why do you not want to use it?

--
You received this message because you are subscribed to the Google Groups "google-http-java-client" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-http-java-...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[David Fuelling]

Great point and question, though I'm not sure I agree with your premise about @Key-support being the main attraction of using this library.

For my purposes, the main attraction is Appengine support.  Google-http-client uses URLFetch under the covers, which provides some nice benefits.  One good one is that URLFetch is advertised to be fronted by an HTTP 1.1 proxy, which provides response caching (I think) that would otherwise not be easily available on appengine (Note that java.net.ResponseCache is a restricted appengine library, so something like Apache's CachingHttpClient is not usable, even if one did want to use ApacheHttpClient).

(Somebody please correct me there if I'm wrong)

As for not wanting to use @Key -- I have a pre-existing set of common pojos that model my REST representations, and I'd like to use this code for both my client and server.  So, it seems weird to have to go and re-factor my common pojo library, redeploy my REST server code (and thus add an unnecessary dependency on google-http-client-java into my server-side code) just to make my client work.

Thanks!

david

To unsubscribe from this group and stop receiving emails from it, send an email to google-http-java-client+unsub...@googlegroups.com.

[David Bullock]

Hi again,

You could use just URLFetch directly? That's the least coupling, most freedom, which you seem to value  https://developers.google.com/appengine/docs/java/urlfetch/  

On the other hand, if you like/appreciate the abstractions provided by com.google.api.client.http.HttpTransport and its friends, are the POJOs-as-you-have-coded-them-thus-far and the POJOs-as-GHJC-wants-them very different?  Can't you just annotate with com.google.api.client.util.Key for the sake of the client, and ignore it on the server where you've already got things as you like them?  Could this be achieved with just some light refactoring?  Could having different POJO representations for client/server be an opportunity you're missing (do you gain much by coupling your client to the server at any level higher than the wire protocol?  You certainly lose flexibility to evolve each independently)?

If you still want the abstractions of GHJC, but not the parsing/serializing behaviour involving the @Key annotation (preferring instead, your own strategy which you have already implemented anyway), then yes: implementing specializations of HttpFactory, HttpParser and HttpContent is the right approach.  Since your objective is to use your own approach for serializing/deserializing, it's possible that subclassing the existing Json* implementations of these will be more work (and 'uglier') than simply implementing HttpFactory and friends directly.  com.google.api.client.json.jackson2.JacksonFactory may be of some use for a clean implementation. 

cheers,

David.

To unsubscribe from this group and stop receiving emails from it, send an email to google-http-java-...@googlegroups.com.