Enable injection of other Jackson modules in FeignJaxRsClientBuilder about conjure-java-runtime HOT 6 CLOSED

We can talk about adding those by default, but I don't think we want to let
users customize the serialization.

On Fri, Sep 30, 2016, 02:17 henryptung [email protected] wrote:

Jdk8Module and JodaModule are prime candidates for usage in certain
application APIs, but the current builder never exposes the created
ObjectMapper for further configuration.

As a particular example, some APIs currently take Map<String, Object>
configuration maps, ostensibly for custom bean serialization. However, if
those beans contain Joda types or Java 8 Optionals, serialization will fail.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#241, or mute the thread
https://github.com/notifications/unsubscribe-auth/AGOdwVQcqZoOiEze08H7WtY7g6OZdomuks5qvNN_gaJpZM4KK4tY
.

from conjure-java-runtime.

@uschi2000 What's the rationale for not allowing customization? I think the current case is a very good example of overprotective API (i.e. can protect a developer from a working setup). I have no issue with strongly recommending a safe API that does not customize, but that doesn't need to come at the cost of handcuffing a developer who does know what they're doing.

from conjure-java-runtime.

If you inject Jackson modules into the config, you'll need to distribute and make sure all of your API consumers have up-to-date Jackson-version-compatible copies of that module at runtime – that's not something we'd like to support because it means that API-definers get to strictly dictate Jackson versions for programs running clients. We don't want to support this because the versions dictated by two programs may not in fact match, making it impossible to load/render the clients.

from conjure-java-runtime.

True; but while the APIs themselves may not dictate any versions, http-remoting does. Version compatibility is inherently a problem either way; for example, if I need to use http-remoting and Glutton in the same app, I will still need to resolve versions. Generally speaking, if we're going to choose one Jackson version anyway, shouldn't we go with newest? I think generally demanding that actively used Jackson libraries/utilities be kept up to date with newest Jackson isn't a crazy demand, and newest is more likely backwards-compatible than old is to be forwards-compatible.

from conjure-java-runtime.

They are orthogonal issues: (1) we need to pick the most compatible jackson
version, (2) [Mark's and my point from before] http-remoting needs to
define exactly what can be serialized and what cannot. For (1), I agree in
principle that newer is better, but it's not that easy, unfortunately: for
example, there are incompatibilities between 2.6.x and 2.7.x :(

On Mon, Oct 3, 2016 at 6:02 PM henryptung [email protected] wrote:

True; but while the APIs themselves may not dictate any versions,
http-remoting does. Version compatibility is inherently a problem either
way; for example, if I need to use http-remoting and Glutton in the same
app, I will still need to resolve versions. Generally speaking, if we're
going to choose one Jackson version anyway, shouldn't we go with newest?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#241 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGOdwWupaK6OTWPpB3-PWimFHBiNyk5Qks5qwaV-gaJpZM4KK4tY
.

from conjure-java-runtime.

@uschi2000 I guess my point is that "most compatible" doesn't seem like an objective measure to me. API version compatibilities is, to me, a tradeoff between API publishers and consumers (servers and clients); I'm not sure how deciding that tradeoff for all APIs at a single point is appropriate and/or useful.

As a salient example, I may want to use a JSR 310 type in my API - this can support pre-JDK8 clients due to backported libraries, but the appropriate module also depends on the client's Java version. This doesn't seem appropriate for http-remoting to deal with, as each client should decide how it wants to consume the given API.

As a second salient example, the Afterburner module can speed up serialization for large-scale use cases, but I have also run into bugs where I need to avoid it to allow some more obscure constructs (like @JsonUnwrapped) to work properly. This, too, doesn't seem like something appropriate to decide in a one-for-all manner.

That said, this is not a critical need for me at the moment - just was a concern I wanted to flag, though I've probably already missed the bus on this one.

from conjure-java-runtime.