[SOLVED] @JsonProperty Unsuccessfully trying to parse the PascalCase.

[Sergei Prosvirnin]

My task is to get a callback from an ASP.NET application which uses PascalCase, not fooBar -> FooBar unlike Java. I am using the model below where @JsonProperty is logically used, but unfortunately I don't see the effect, I can only see the result of serialization if I send camelCase. Why this annotation doesn't work?

import com.fasterxml.jackson.annotation.JsonInclude;
import com.fasterxml.jackson.annotation.JsonProperty;
import com.fasterxml.jackson.annotation.JsonPropertyOrder;

@JsonInclude(JsonInclude.Include.NON_NULL)
@JsonPropertyOrder({
        "Result",
        "TransactionId",
        "Error",
        "ErrorDescription"
})
public class CallbackCheckSignRqDto {

    @JsonProperty("Result")
    private String result;
    @JsonProperty("TransactionId")
    private String transactionId;
    @JsonProperty("Error")
    private String error;
    @JsonProperty("ErrorDescription")
    private String errorDescription;

    @JsonProperty("Result")
    public String getResult() {
        return result;
    }

    @JsonProperty("Result")
    public void setResult(String result) {
        this.result = result;
    }

    @JsonProperty("TransactionId")
    public String getTransactionId() {
        return transactionId;
    }

    @JsonProperty("TransactionId")
    public void setTransactionId(String transactionId) {
        this.transactionId = transactionId;
    }

    @JsonProperty("Error")
    public String getError() {
        return error;
    }

    @JsonProperty("Error")
    public void setError(String error) {
        this.error = error;
    }

    @JsonProperty("ErrorDescription")
    public String getErrorDescription() {
        return errorDescription;
    }

    @JsonProperty("ErrorDescription")
    public void setErrorDescription(String errorDescription) {
        this.errorDescription = errorDescription;
    }

}

@RequestMapping(value = "/callback", method = RequestMethod.POST)
    @ResponseBody
    public ResponseEntity callback(@RequestBody CallbackCheckSignRqDto callbackCheckSignRqDto)

JDK 1.8

Output for $ mvn dependency:tree -Dverbose - https://gist.githubusercontent.com/sergey-prosvirnin/694f630fb04a33d1cfe530715c7f9396/raw/4c59e1c46dd7bca161a1cee100b5ae91db614ee6/$%2520mvn%2520dependency:tree%2520-Dverbose

[Rob Spoor]

Are you sure that Jackson is being used here? I've worked with WebLogic, and that used MOXy out-of-the-box. I think that JBoss tries to use JSON-P by default. Maybe your server uses one of these, or something else.

[Sergei Prosvirnin]

Rob Spoor wrote:Are you sure that Jackson is being used here? I've worked with WebLogic, and that used MOXy out-of-the-box. I think that JBoss tries to use JSON-P by default. Maybe your server uses one of these, or something else.

Yes, the rest of Jackson's annotations work great in this project, I use Tomcat.

[Stephan van Hulst]

Why do you have annotations on both your fields and your getters/setters?

[Sergei Prosvirnin]

Stephan van Hulst wrote:Why do you have annotations on both your fields and your getters/setters?

This is autogeneration of pugin jsonschema2pojo - https://github.com/joelittlejohn/jsonschema2pojo

[Ron McLeod]

Can you share an example of the JSON representation which is not being deserialized correctly?

[Sergei Prosvirnin]

Ron McLeod wrote:Can you share an example of the JSON representation which is not being deserialized correctly?

Unsuccess - HTTP Status 400

{
    "Result": "success",
    "TransactionId": "GUID",
    "Error": "",
    "ErrorDescription": ""
}

Success

{
    "result": "success",
    "transactionId": "GUID",
    "error": "",
    "errorDescription": ""
}

[Stephan van Hulst]

I think it just completely ignores your annotations and uses the default names derived from your getters and setters to populate the object. How do you know that the annotations works correctly in the rest of the project?

[Sergei Prosvirnin]

Stephan van Hulst wrote:I think it just completely ignores your annotations and uses the default names derived from your getters and setters to populate the object. How do you know that the annotations works correctly in the rest of the project?

For example such announcements work as expected.

import com.fasterxml.jackson.annotation.JsonInclude;
import org.codehaus.jackson.map.annotate.JsonSerialize;

import java.util.Date;

@JsonInclude(JsonInclude.Include.NON_NULL)
@JsonSerialize(include = JsonSerialize.Inclusion.NON_NULL)

[Ron McLeod]

Sergei Prosvirnin wrote:For example such announcements work as expected.

import com.fasterxml.jackson.annotation.JsonInclude;
import org.codehaus.jackson.map.annotate.JsonSerialize;

import java.util.Date;

@JsonInclude(JsonInclude.Include.NON_NULL)
@JsonSerialize(include = JsonSerialize.Inclusion.NON_NULL)

Those annotations are used during serialization - your issue is during deserialization.

[Ron McLeod]

I don't think there the problem is with your annotated DTO. I used it in a simple Quarkus (not Spring) based project, and the payload deserialized as expected.

@Path("/callback")
@Consumes(MediaType.APPLICATION_JSON)
public class CallbackResource {

    @POST
    public String callback(CallbackCheckSignRqDto callbackCheckSignRqDto) {
        System.out.println("CallbackResource.callback(): " + callbackCheckSignRqDto);
        return "Thanks!";
    }

}

{    "Result": "success",    "TransactionId": "GUID",    "Error": "",    "ErrorDescription": "" }CallbackResource.callback(): CallbackCheckSignRqDto [error=, errorDescription=, result=success, transactionId=GUID]

[Sergei Prosvirnin]

Ron McLeod wrote:I don't think there the problem is with your annotated DTO. I used it in a simple Quarkus (not Spring) based project, and the payload deserialized as expected.

@Path("/callback")
@Consumes(MediaType.APPLICATION_JSON)
public class CallbackResource {

    @POST
    public String callback(CallbackCheckSignRqDto callbackCheckSignRqDto) {
        System.out.println("CallbackResource.callback(): " + callbackCheckSignRqDto);
        return "Thanks!";
    }

}

{    "Result": "success",    "TransactionId": "GUID",    "Error": "",    "ErrorDescription": "" }CallbackResource.callback(): CallbackCheckSignRqDto [error=, errorDescription=, result=success, transactionId=GUID]

Thank you for this test, I am flattered by your involvement. I found a solution in the form of using the old version of the package (funny, usually on the forums they advise to change to the new one).

import org.codehaus.jackson.annotate.JsonProperty;

[Ron McLeod]

For your reference - I tested with version 2.12.1, which is only a few months behind the latest.

Also, I noticed from your POM tree that you were using version 2.6.3 for jackson-databind, and version 2.9.8 for jackson-annotations and jackson-core.  The different versions may have not been compatible (databind has a dependency on both annotations and core).

[Rob Spoor]

Sergei Prosvirnin wrote:I found a solution in the form of using the old version of the package (funny, usually on the forums they advise to change to the new one).

import org.codehaus.jackson.annotate.JsonProperty;

That's Jackson 1.x which has been inactive for a long, long time. The latest release I could find on Maven Central is from 2013.

Jackson is (unfortunately) known for vulnerabilities that are found quite often (at least partly because of its extensive feature set), so you definitely don't want to use a version that's almost 8 years old. As long as you monitor for these vulnerabilities and update as soon as one is found, you should be pretty safe.

For monitoring I use Snyk.io (free account), but at work we use Jenkins with the OWASP dependency checker. There are probably other solutions as well.

Ron McLeod wrote:Also, I noticed from your POM tree that you were using version 2.6.3 for jackson-databind, and version 2.9.8 for jackson-annotations and jackson-core.  The different versions may have not been compatible (databind has a dependency on both annotations and core).

This could very well be the cause of the issue. Certain library sets rely on using compatible versions. For instance, all Jackson libraries should have the same version; all POI libraries should have the same version; all Quarkus libraries should have the same version. If you have different versions, the results can be unpredictable. I've seen quite a number of NoSuchMethodError and similar errors because of version mismatches. Your case could well be that, although you don't get errors, something else goes wrong.

[Sergei Prosvirnin]

Rob Spoor wrote:

Sergei Prosvirnin wrote:I found a solution in the form of using the old version of the package (funny, usually on the forums they advise to change to the new one).

import org.codehaus.jackson.annotate.JsonProperty;

That's Jackson 1.x which has been inactive for a long, long time. The latest release I could find on Maven Central is from 2013.

Jackson is (unfortunately) known for vulnerabilities that are found quite often (at least partly because of its extensive feature set), so you definitely don't want to use a version that's almost 8 years old. As long as you monitor for these vulnerabilities and update as soon as one is found, you should be pretty safe.

For monitoring I use Snyk.io (free account), but at work we use Jenkins with the OWASP dependency checker. There are probably other solutions as well.

Ron McLeod wrote:Also, I noticed from your POM tree that you were using version 2.6.3 for jackson-databind, and version 2.9.8 for jackson-annotations and jackson-core.  The different versions may have not been compatible (databind has a dependency on both annotations and core).

This could very well be the cause of the issue. Certain library sets rely on using compatible versions. For instance, all Jackson libraries should have the same version; all POI libraries should have the same version; all Quarkus libraries should have the same version. If you have different versions, the results can be unpredictable. I've seen quite a number of NoSuchMethodError and similar errors because of version mismatches. Your case could well be that, although you don't get errors, something else goes wrong.

This is a rather large and old project, and in this case it is now impossible to upgrade to a new version, even due to the broken code of colleagues. Thanks for the help!

[Rob Spoor]

You're welcome.