Currently, WildFly's behaviour is not aligned with with other application servers when JSON is deserialized into POJOs.

Unrecognized properties

UnrecognizedPropertyException - The property is in the JSON, but not in the POJO. Other application servers ignore such properties

public class SomeDTO{
private String property1;

//Getters and setters
}

{
"property1": "This one will not cause any troubles",
"property2": "This one causes UnrecognizedPropertyException istead of being ignored"
}

To fix this behavior, provided dependency on arbitraty Jackson version must be present in the project and @JsonIgnoreProperties annotation must be used.

@JsonIgnoreProperties(ignoreUnknown = true)
public class SomeDTO {
private String property1;

//Getters and setters
}

Programs without @JsonIgnoreProperties annotation are very fragile in production (the API contract may change (one moje property added) and the whole client goes down.

Property naming

Property naming - POJO attribute naming are what matters elsewhere. In WildFly, @JsonProperty annotation must be used to tell Jackson the correct name of the POJO, since all the attribute names are for some reason converted into lower case. This also results in UnrecognizedPropertyException.

This code will not work

public class Rates {

    private BigDecimal AUD;
}

for this JSON:

{
"AUD": 1.334523
}

The resulting error is:

Unrecognized field "AUD" (class entity.Rates), not marked as ignorable (31 known properties: "aud",....

However, when @JsonProperty annotation is used on the field, things suddenly work:

public class Rates {
    @JsonProperty("AUD")
    private BigDecimal AUD;
}

Jackson annotations provided dependency must be used almost every time to ensure application stability in production. This is less problematic nowadays, when near every application server contains Jackson. When Java EE 8 comes, this will be even more controversial:

        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-annotations</artifactId>
            <version>2.8.6</version>
            <scope>provided</scope>
        </dependency>

Behavior of other application servers

There is a sample JAX-RS client/sever application on GitHub. When deployed without Jackson annotations, it works perfectly in:

1. Glassfish 4
2. Payara 171 /obviously, should be the same as Glassfish/
3. TomEE
4. Websphere Liberty

Other AS were not tested.

Please note, there is also the problem with Resteasy not creating HTTP pools, causing problems when calling WebTarget conncurrently. The sample application may cause errors in WildFly when called concurrently.

Proposal summary

I propose adopting behavior of other application servers - no Jackson annotations required by default. Missing properties being ignored by default, as well as correcting the property name resolution.