Or i will haver to do one of those?

@gmaciel can you give a small example of code?

something like this for instance

enum class Test {
        @JsonProperty("ii")       II,
        @JsonProperty("i")        I;
    }

if i pass a value that is not

i

or

ii

it breaks

so for me i wouild have to use a

JsonCreator

for the enum and parse it myself

or a Deserializer

if you pass a value to the annotation, or if the JSON contains a different value?

so i’m wondering if theres a way to make it not fail when theres no json value mapped

the json has a different value

it might be the normal deserialization feature for ignoring extra properties

READ_UNKNOWN_ENUM_VALUES_AS_NULL
READ_UNKNOWN_ENUM_VALUES_USING_DEFAULT_VALUE

probably not those, because they deal with the enum itself not its properties.

FAIL_ON_UNKNOWN_PROPERTIES

would normally be the setting for missing properties

those settings affect everything you use on that mapper, and seems like the last being set to FALSE does what you want.

if not, then we need to check if it is issue with databind or with the module.

it doesn’t work for enum apparently, but i will do some more testing

I had to exclude explicitely

kotlin-reflect

coming with Jackson to avoid having

kotlin-reflect:1.0.6

even if iI declare explicitely

kotlin-reflect:1.1.1

in my Gradle config. https://github.com/mix-it/mixit/commit/7e75be7b62c339b5f004ce2dcaf6cf2c78feb87c

I guess I am not the only one who will have this issue

Do you confirm this is the right way to handle that? In // I am trying to see if we could manage Kotlin version dependencies at Spring Boot / Spring IO platform level

Using https://spring.io/blog/2016/12/16/dependency-management-plugin-1-0-0-rc1 for Gradle and dependencyManagement for Maven

@sdeleuze the code was updated for 1.1.0 but no release has happened yet. You should just be able to redeclare the dependency in your Gradle module for reflect at the new version number and it would upgrade it to match.

your exclude / include works as well but shouldn't be neccesary

I'll see if I can push for a new 2.8.x release soon of that module

@hackerham has left the channel

need some help: [json - Can I pass type information to simplify this somehow? - Stack Overflow](https://stackoverflow.com/questions/43131803/can-i-pass-type-information-to-simplify-this-somehow/43132243?noredirect=1#comment73365688_43132243)

@wesbillman has left the channel

I have a following data class in kotlin. The deserializer fails randomly by selecting the second constructor. If I remove the second constructor, it always works. I added @JsonCreator annotation, why jackson uses the second constructor sometimes?

data class PostalAddress @JsonCreator constructor(
        val streetAddress1: String? = null,
        val streetAddress2: String? = null,
        val city: String? = null,
        val stateProvince: String? = null,
        val postalCode: String? = null,
        val postalCodePlusFour: String? = null,
        val countryCode: String? = null,
        val validated: Boolean? = null
) : Serializable {
    constructor(@JsonProperty("postalCode") postalCode: String) : this(null, null, null, null, postalCode, null, null, false)

@kerdosa can you report this to the issues tracker along with a test case showing the problem there. Looks like a bug because it should favor the primary constructor. It might be databind picking the string-only constructor thinking it is a magical constructor that accepts a string JSON and does its own binding. If so, it will be hard to fix in the module. You can test it by adding a second parameter to see if that was the issue. Otherwise report it here: https://github.com/FasterXML/jackson-module-kotlin/issues

I am wondering what the suffix pr* in versions 2.9.0.pr1 and 2.9.0.pr2 stands for. Is it a stable version or some sort of release candidate?

I've created a custom deserializer and am using @JsonDeserialize to attempt to use it like so:

data class Diagnosis(@JsonIgnore @Id val id: ObjectId? = null,
                     @JsonProperty("apuid") val apuId: Int,
                     @JsonProperty("RecordID") val recordId: String,
                     @Indexed val patientId: String,
                     val patientAccountNo: String,
                     val encounterId: String,
                     val encounterDate: LocalDate,
                     @JsonProperty("ProviderNPI") val providerNpi: String?,
                     @JsonProperty("ICDCode") val icdCode: String?,
                     val name: String,
                     @JsonDeserialize(contentUsing = LenientLocalDateDeserializer::class) @JsonFormat(pattern = "M/d/yyyy") val assessmentOnsetDate: LocalDate?)

I'm finding that when I run the code though the regular LocalDateSerializer is used. I've tried the

using

argument as well but it doesn't seem to have any effect.

I'm using the with the CSV module, BTW, in case it matters.