So I realized I am not actually getting JSON in the `@PostMapping` so it won't use Jackson at all. C...

# spring

[poohbar]

So I realized I am not actually getting JSON in the @PostMapping so it won't use Jackson at all. Can Spring bind form data to Kotlin data class?

[mp]

@PostMapping(value = ["/upload"], produces = arrayOf("application/json;charset=UTF-8"))
    @ResponseBody
    fun uploadStlFile(
            @RequestParam(required = true) file: MultipartFile
    )

[poohbar]

your endpoint consumes files, mine:

consumes = MediaType.APPLICATION_FORM_URLENCODED_VALUE

[mp]

I think you will be able to handle form data with spring 😃 if its possible to handle files with miltipart

[poohbar]

I don't think so..
In this example it works when PersonDTO is a java class but not when it is a Kotlin data class

@PostMapping(value = "/submit", consumes = MediaType.APPLICATION_FORM_URLENCODED_VALUE)
public String submit(PersonDTO data)

[thatadamedwards]

that might be because of reflection

[thatadamedwards]

Kotlin data classes must have all fields populated once construction is done

[thatadamedwards]

but if you provide default values to your fields and make those fields var, you might make some headway

[thatadamedwards]

I’m imagining that Spring is trying to create an instance of your DTO, and then call the appropriate setters on the fields it has found

[thatadamedwards]

so I’m imagining your PersonDTO might look like:

data class PersonDTO (
    val firstName: String,
    val lastName: String,
    val email: String
)

[thatadamedwards]

but what you might need is something like:

data class PersonDTO (
    var firstName: String = "",
    var lastName: String = "",
    var email: String = ""
)

[thatadamedwards]

this way, PersonDTO has a default constructor, and you can set the field values post-construction

[thatadamedwards]

I could be completely wrong though

[poohbar]

I think you are exactly right except one there is one problem:

I don't like mutable Kotlin data classes. 😄

[thatadamedwards]

I think you can make a workaround for that with kotlin-reflect and everything

[thatadamedwards]

I know I did something similar for data classes and Spring Data

[thatadamedwards]

lemme check something real quick

[thatadamedwards]

https://kotlinlang.org/docs/reference/compiler-plugins.html#no-arg-compiler-plugin

[thatadamedwards]

so yeah - I use this so that I can instantiate @Entity data classes with a no-arg constructor

[thatadamedwards]

but still keep my immutability

[thatadamedwards]

what you could do is create a marker interface like interface DTO and then have @DTO data class PersonDTO

[thatadamedwards]

seems like an extra step and feels very much like Guice

[thatadamedwards]

but that’s not to say it’s a bad practice or anything