best way to handle changing JSON field names?

[JP]

Hi all,

Is there an eloquent way to handle the scenario where the JSON string field names may be changing (depending on environment)?

In development environment:
{ "id" : 1234, "name1" : "John" }

In production environment:
{ "id" : 1234, "name2" : "John" }

What I really want is the ability to do this to my POJO object:

@JsonProperty("${env.nameField}")
private String name;

Basically, a way to externalize the @JsonProperty annotation configuration in a properties file so that it's controlled by the respective deployment packaging.

However, since the above is not possible, what is the next best way to handle this scenario?

Thanks!
jp

[Tatu Saloranta]

There is no support for such variations at this point. I suspect most users would first bind JSON into Map or JsonNode, manipulate it into some sort of canonical representation, then use databinding.

-+ Tatu +-

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user+unsubscribe@googlegroups.com.
To post to this group, send email to jackso...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[JP]

Thanks, Tatu.

I think this would be a useful feature to have perhaps in a future release? ;)

Especially considering there are more and more user-configurable systems offering REST APIs (eg. JIRA) where fields names will be changing.

Best regards,
jp

[Tatu Saloranta]

As a general answer, I am always open to new ideas. :)

In this specific case I am not quite sure how this could be implemented, considering the way Jackson handles properties and introspection.

However... come to think of this, there is one piece of configurability that might help here. `PropertyNamingStrategy` may be used to change name mapping from POJO property (derived from getter/setter, field, or annotation) to/from external name used in JSON. It is therefore possible to have different strategy, and one that does not have to merely change casing or punctuation but may completely change the name.

One downside with this is that you can not dynamically change the strategy; it is static setup (set once per ObjectMapper), so you'd need separate mapper for each distinct deployment. That may or may not work for you.

-+ Tatu +-

--

[JP]

Hi Tatu,

Thanks for the tip about PropertyNamingStrategy!

However, I couldn't get it to work...  I created my own class extending the PropertyNamingStrategy class, and overrode the nameForField(), nameForGetterMethod(), nameForSetterMethod() functions.  I created an instance of this class and added it to my ObjectMapper using the setPropertyNamingStrategy() method.

But during execution, my overridden methods were not called.  My POJO has all the fields and also the setters/getters annotated wtih @JsonProperty as well.

There are no errors.  My POJO still gets populated with the JSON values.  However, my PropertyNamingStrategy class does not seem to get used during execution.

Is there some other ObjectMapper configuration I need to set to trigger the use of the PropertyNamingStrategy? 

Thanks,
jp

On Wednesday, August 24, 2016 at 2:18:11 PM UTC-4, Tatu Saloranta wrote:

As a general answer, I am always open to new ideas. :)

In this specific case I am not quite sure how this could be implemented, considering the way Jackson handles properties and introspection.

However... come to think of this, there is one piece of configurability that might help here. `PropertyNamingStrategy` may be used to change name mapping from POJO property (derived from getter/setter, field, or annotation) to/from external name used in JSON. It is therefore possible to have different strategy, and one that does not have to merely change casing or punctuation but may completely change the name.

One downside with this is that you can not dynamically change the strategy; it is static setup (set once per ObjectMapper), so you'd need separate mapper for each distinct deployment. That may or may not work for you.

-+ Tatu +-

On Wed, Aug 24, 2016 at 10:28 AM, JP <padaw...@gmail.com> wrote:

Thanks, Tatu.

I think this would be a useful feature to have perhaps in a future release? ;)

Especially considering there are more and more user-configurable systems offering REST APIs (eg. JIRA) where fields names will be changing.

Best regards,
jp

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.

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

[Tatu Saloranta]

I think what you bumped into was

   MapperFeature.ALLOW_EXPLICIT_PROPERTY_RENAMING

(defaulting to false)

which governs whether explicitly named properties (ones with `@JsonProperty`) are renamed or not.

Default assumption is that if you have explicit denoted name to use, that should stick (otherwise no overrides were possible). However, if you want, you can allow renaming even in those cases.

So you want to enable this feature.

It may even be renamed for individual properties, although presumably in that case explicit renaming may be simpler.

Similarly it's not clear whether you should use `@JsonProperty`, unless it is to increase visibility.

I suspect that plain `@JsonProperty` with no String (defaulting to "") should be renamed regardless, but haven't tested it (if it's not that seems like a flow as that case does not specify explicit name).

-+ Tatu +-

To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user+unsubscribe@googlegroups.com.

[JP]

Thank you very much, Tatu!   It works now!  XD

Cheers!
jp