It is not possible to customize the extraction of the properties of a pojo that is represented as a model

[marcuslange]

Describe the bug
BeanUtils creates a new ObjectMapper in method extractProperties. Since this ObjectMapper is not configured with JavaTimeModule, it throws exceptions on Java 8 date/time classes.

java.lang.IllegalArgumentException: Java 8 date/time type java.time.LocalDate not supported by default: add Module "com.fasterxml.jackson.datatype:jackson-datatype-jsr310" to enable handling (through reference chain: com.swacorp.cbna.poc.documentdb.adapter.primary.rest.resource.LineSolutionResource["startDate"])

To Reproduce
Return an object that contains a property of LocalDate

Expected behavior
I would expect that this class would use the configured ObjectMapper.

Environment:

• Spring HATEOAS Siren version 1.2.0
• Spring Boot version 2.5.2
• Spring Framework version 5.3.8

[ingogriebsch]

Hi @marcuslange! Thank you for creating the ticket. I will look at the problem in detail and then give you feedback. :)

[ingogriebsch]

@marcuslange You can expect to get this bug fixed this weekend! :)

[ingogriebsch]

Hey @marcuslange, I just took a closer look at the problem.

I haven't quite understood the behavior yet. But it looks like you just need to make sure that the library mentioned in the error message is part of the classpath. It doesn't seem to be necessary to explicitly configure the ObjectMapper you mentioned, which is used in the BeanUtils class.

I have adapted the corresponding samples project here so that the data model there uses a property of type LocalDate. The samples project uses the current SNAPSHOT version of the Spring HATEOAS Siren library (which I did not change yet). The Samples project contains the library mentioned in the error message in the classpath. When I remove the library from the classpath, I get an error message similar to the one you got.

So can you please first check if your project has the library mentioned in the error message in the classpath? And can you please add the library to the classpath if not and check again how the project behaves?

[marcuslange]

I just verified that the fat jar does contain the jsr310 jar. I did notice that I use the hateoas starter and that you are not. I changed that, and am still receiving the same error.

this is my current deps set up:

                implementation(platform("org.springframework.boot:spring-boot-dependencies:${springBootV}"))
		compileOnly(platform("org.springframework.boot:spring-boot-dependencies:${springBootV}"))
		annotationProcessor(platform("org.springframework.boot:spring-boot-dependencies:${springBootV}"))
		implementation 'org.springframework.boot:spring-boot-starter-data-jdbc'
		implementation 'org.springframework.boot:spring-boot-starter-web'
		implementation 'org.springframework.hateoas:spring-hateoas'
		implementation 'org.springframework.boot:spring-boot-starter-actuator'
		implementation 'de.ingogriebsch.hateoas:spring-hateoas-siren:1.2.0'
		implementation 'org.springframework.boot:spring-boot-starter-aop'
		implementation 'com.fasterxml.jackson.datatype:jackson-datatype-jsr310'
		implementation 'org.flywaydb:flyway-core'
		implementation 'javax.inject:javax.inject:1'
		compileOnly 'org.projectlombok:lombok'
		runtimeOnly 'org.postgresql:postgresql'
		annotationProcessor 'org.projectlombok:lombok'
		testImplementation 'org.springframework.boot:spring-boot-starter-test'

[marcuslange]

I pulled the code and tested locally.
Adding .findAndRegisterModules() fixed the issue in my configuration. Below are the changes to BeanUtils.

static Map<String, Object> extractProperties(Object object, String... excludes) {
        Map<String, Object> properties = new ObjectMapper()
                .findAndRegisterModules()
                .convertValue(object, new TypeReference<Map<String, Object>>() {
                });

        for (String exclude : excludes) {
            properties.remove(exclude);
        }

        return properties;
    }

[ingogriebsch]

Hey @marcuslange I still do not completely understand the root of the problem. Using the starter mainly helps to ease which dependencies are part of your project. In this case it should not make a difference if the starter is used or not because the starter is not responsible for adding Jackson related dependencies to a project.

But even if I still need to understand why my samples project is working without any code change but yours is not, I refactored the code so that is is now using an ObjectMapper instance that can be customized by the client.

Means, you can add a @Bean of type SirenConfiguration to your application-context and use method withObjectMapperCustomizer to customize the ObjectMapper instance that is used to extract the properties.

You should be able to request the latest SNAPSHOT dependency from the SonaType Snapshots Repository.

It would be really nice if you would let me know if this approach works for you! :)

[ingogriebsch]

Hey @marcuslange I would like to ask if you already had the chance to check if the current SNAPSHOT is working fine for you. It would be really nice to hear from you! :)

[ingogriebsch]

Hey @marcuslange do you have any feedback for me?

[marcuslange]

Sorry to leave you hanging. We decided not to use siren. There an issue with the specification that HAL-Forms solved, so went that direction.

[ingogriebsch]

Hi @marcuslange! Nice to hear from you! And no problem that you decided for another Hypermedia dialect! :)

Out of curiosity: which issue could you solve with HAL-Forms but not with Siren?

[marcuslange]

@ingogriebsch, it's the options element on a property to add additional details (like enum values) to a property.

[ingogriebsch]

Done!