HAL Forms properties should consider Jackson constructors

[reda-alaoui]

Hello,

Let's consider the following controller:

@RequestMapping("/foos")
public class FooController {

  @GetMapping
  public ResponseEntity<?> list() {
    return ResponseEntity.ok(
          new CollectionModel<>(
              Collections.emptyList(),
              selfLink.andAffordance(
                  afford(
                      methodOn(FooController.class).create(null)))));
  }

  @PostMapping
  public ResponseEntity<?> create(@RequestBody CreateCommand command) {
    //...
  }

  private static class CreateCommand {
    private final String name;
    
    @JsonCreator
    CreateCommand(@JsonProperty("name") String name){
      this.name = name;
    }
  }
}

FooController#list produces:

{
  "_links": {
    "self": {
      "href": "http://localhost:8080/foos"
    }
  },
  "_templates": {
    "default": {
      "method": "post",
      "properties": []
    }
  }
}

As you can see, property name is missing.

[gregturn]

Intriguing.

I crafted a test case matching your scenario, and it actually showed the attribute you said was missing. But I tracked it down to the getter method.

So this gives me a good arena to work on.

[reda-alaoui]

What do you mean by I tracked it down to the getter method?
There is no getter in the scenario.

I forgot to say that jackson autodetection is disabled in my environment (#1147):

objectMapper
        .disable(AUTO_DETECT_CREATORS)
        .disable(AUTO_DETECT_FIELDS)
        .disable(AUTO_DETECT_GETTERS)
        .disable(AUTO_DETECT_IS_GETTERS)
        .disable(AUTO_DETECT_SETTERS)
        .disable(SerializationFeature.FAIL_ON_EMPTY_BEANS);

And I am using version 1.0.4.RELEASE

[reda-alaoui]

And please note that adding getter getName for name makes the property appear but with readonly : true.

[gregturn]

What I meant is that as soon as Spring HATEOAS can spot a getName(), it will transform that into a property of called "name", and even evaluate Jackson annotations related to the getter. It will also uses the existence of setName() to glean the value of readyOnly.

By dropping that, I am working on a way to read the constructor method with JsonCreator annotation, and find all the JsonProperty -related attributes.

The one thing to figure out is if there are both (a getName() AND a JsonCreator constructor call), which one takes precedence. My assumption would be the getter.

Also, if this works @odrotbohm and I can assess whether or not to backport it to 1.0.

[gregturn]

I can see test cases encompassing:

private static class CreateCommand {

    String name;

    @JsonCreator
    CreateCommand(@JsonProperty("otherName") String name) {
        this.name = name;
    }
}

The resulting JSON should use otherName. However, readOnly is a bit fuzzy. There is no setter, but you CAN populate via the constructor.

@Data
private static class CreateCommand {

    String name;

    @JsonCreator
    CreateCommand(@JsonProperty("otherName") String name) {
        this.name = name;
    }
}

Should this one find name, but then let otherName supercede it? Or should both properties stand given there is a getter and setter for name?

[reda-alaoui]

I would say both properties stand.
Because, IMO, we can’t be sure that name attribute is initialised with otherName value inside the constructor.

[reda-alaoui]

Although, maybe jackson just ignores any setter when it finds a JsonCreator?

[gregturn]

@odrotbohm and I discussed this in a bit more detail, and realized there is a whole story connected to this that needs to be evaluated. Thus, we've moved this into 1.2.

Essentially, it's possible to create an immutable type where you have no setters. Instead, everything is built upon either constructor calls or "@With" or whatever, and the existing code would PROBABLY misread the "readOnly" nature of those types.

We need to expand the existing set of unit tests to cover such scenarios, and then potentially entertain a "hint" annotation that could be applied to properties, constructors, and even getters/setters. That way, Spring HATEOAS can try to guess as best as it can, but in the corner cases where it can't figure it out, grant users ability to mark up their code to help HAL-FORMS render things as desired.