Resteasy and Kotlinx Serialization #9003
Comments
|
cc @evanchooly |
emmanuelbernard
added
the
kind/extension-proposal
emmanuelbernard
moved this from Backlog
to 1.8 plan - Early September
in General Roadmap (deprecated)
|
@evanchooly Any updates here, or should this be moved to 1.9? |
|
Definitely move it
…On Wed, Sep 9, 2020, 11:37 PM Jason T. Greene ***@***.***> wrote:
@evanchooly <https://github.com/evanchooly> Any updates here, or should
this be moved to 1.9?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9003 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABPTTL2FPPOVVNSGUPBTY3SFBCXTANCNFSM4MW7J6QA>
.
|
n1hility
moved this from 1.8 plan - Early September
to 1.9 plan - Early October
in General Roadmap (deprecated)
n1hility
moved this from 1.9 plan - Early October
to 1.10 plan early november
in General Roadmap (deprecated)
|
And update on this? I am getting the following "Class initialization of kotlinx.serialization.internal.IntSerializer failed." error when try to build native image. |
n1hility
moved this from 1.10 Done - early november
to 1.12 Plan
in General Roadmap (deprecated)
|
@n1hility is there anything pointer on how this should be done? So that others can take a crack at it? Or any suggestion on how these used kotlinx serialization extensively move to quakrus? Many thanks. |
|
@evanchooly is looking into this (and I'll be helping if necessary). |
|
Let me describe the use case: @JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy::class)
data class ServerRequest(
val lastName: String,
val firstName: String,
val documentNumber: String,
val typeOfDocument: String,
val mobilePhone: String?,
val dateOfBirth: String?,
)Do not work even on JVM because Jackson does not use the constructor (why???). Ok, fix this by adding to build: implementation("com.fasterxml.jackson.module:jackson-module-kotlin")Quarkus do a good job and do register needed Jackson module. Works fine on JVM! Not so fast - #8479 So, the fight is proceed. Hours of debugging and we remove @JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy::class)
data class ServerRequest @JsonCreator constructor(
val lastName: String,
val firstName: String,
val documentNumber: String,
val typeOfDocument: String,
val mobilePhone: String?,
val dateOfBirth: String?,
)It is just one example of an annoying experience that came from Jackson for Kotlin developer. For simple cases, we migrated to JSON-B. How to fix it? Kotlinx Serialization - it just works in our experience - Ktor (handmade native build), Spring Native. It builds serializers at compile time and this is a gamechanger in the native world. As a bonus, you actually know what you get serialized instead of hoping (and praying) for a good result. Please support us - your Kotlin fans... |
|
The is work in progress on this. You can track it here |
|
#21318 has been merged (and some subsequent fixes have been applied), so we can close this. The first release that will contain this support is |
|
Tryed 2.7.0.CR1 on one-method microservice: @ApplicationScoped
@Path("horoscope")
class Horoscopes{
@GET
@Produces(MediaType.APPLICATION_JSON)
@Path("daily")
suspend fun daily(): List<Horoscope> {
// impl here
}
}
@Serializable
data class Horoscope(val id: Long, val text: String)
Error on JVM and Native: That is because |
|
It's definitely a bug. I'll take care of it. Thanks for trying it out and reporting! |
This was not a problem with Jackson or Jsonb, because they used the object class to determine the type of serializer, but it is needed for Kotlin serialization which actually used the generic type provided in the MessageBodyWriter params to determine the serializer Addresses: #quarkusio#9003 (comment)
This was not a problem with Jackson or Jsonb, because they used the object class to determine the type of serializer, but it is needed for Kotlin serialization which actually used the generic type provided in the MessageBodyWriter params to determine the serializer Addresses: #quarkusio#9003 (comment)
This was not a problem with Jackson or Jsonb, because they used the object class to determine the type of serializer, but it is needed for Kotlin serialization which actually used the generic type provided in the MessageBodyWriter params to determine the serializer Addresses: #quarkusio#9003 (comment) (cherry picked from commit c273a64)
Description
Hello to all. If I am not mistaken, currently the only way to automatically serialise and deserialise objects that we receive/send in the Resteasy HTTP endpoints is using either JsonB or Jackson. I would therefore kindly ask if the default Kotlin serialisation way of using kotlinx.serialization is planned to be supported by Quarkus as a RestEasy extension. As me and I think lot of the current and future Quarkus users, like being able to use Kotlin in Quarkus projects, we would be grateful if kotlinx.serialization and coroutines will be considered as important targets for Quarkus near term future as they are the finishing touches on the decent support of Kotlin in Quarkus.
Thank you so much for your effort.
The text was updated successfully, but these errors were encountered: