Describe the bug
When trying to send something else than a body, or trying to do anything more than simply getting a POJO from a request body, deployment on GCP using GcfJarLauncher fails with ClassCastException: class org.eclipse.jetty.server.Request$1.
Sample
Starting from the example on the website:
@SpringBootApplication
class Application {
@Bean
fun uppercase(): Function<String, String> {
return Function { value -> value.uppercase() }
}
}
fun main(args: Array<String>) {
SpringApplication.run(Application::class.java, *args)
}
For purposes of getting this up-and-running in GCP I used the Shadow plugin and set this up in my gradle build file:
cloudFunctionRun {
target = "org.springframework.cloud.function.adapter.gcp.GcfJarLauncher"
port = 8080
}
tasks.withType<com.github.jengelman.gradle.plugins.shadow.tasks.ShadowJar> {
mergeServiceFiles()
manifest {
attributes(
"Main-Class" to "org.springframework.cloud.function.adapter.gcp.GcfJarLauncher",
"Start-Class" to "com.example.Application",
)
}
}
and deployed via gcloud without issues. The function gets deployed and responds correctly. This is a function that only accepts a body and performs just that. However if I want to build on top of this example and build something else, for example adding URL parameters, suddenly the serialization fails.
ClassCastException: class org.eclipse.jetty.server.Request$1 cannot be cast to class java.lang.String
OK, so I tried exchanging the String to org.eclipse.jetty.server.Request. But that fails too, with:
java.lang.ClassCastException: class org.eclipse.jetty.server.Request$1 cannot be cast to class org.eclipse.jetty.server.Request
And this is the place where I get lost and no other forums seem to have an answer. I found a StackOverflow question and its corresponding GitHub issue where the OP claims it worked with a BufferedReader (goodness me), but surely, there should be a more straightforward way, where I declare that I'll handle the entire Request object and either use BiFunction with both Request and Response, or just handle the Request and return a String. If my digging is correct than the case with Request$1 means that there is some inheritance going on and the object is private, which is the reason why the cast fails. So now - is this something that can be done, or is this an accepted technical debt, nobody knows how to solve this and thus Spring Cloud Functions do not support and will not support anything else beyond body handling?
Thanks a lot, hope my description was clear enough.
Describe the bug When trying to send something else than a body, or trying to do anything more than simply getting a POJO from a request body, deployment on GCP using GcfJarLauncher fails with
ClassCastException: class org.eclipse.jetty.server.Request$1
.Sample Starting from the example on the website:
For purposes of getting this up-and-running in GCP I used the Shadow plugin and set this up in my gradle build file:
and deployed via gcloud without issues. The function gets deployed and responds correctly. This is a function that only accepts a body and performs just that. However if I want to build on top of this example and build something else, for example adding URL parameters, suddenly the serialization fails.
OK, so I tried exchanging the
String
toorg.eclipse.jetty.server.Request
. But that fails too, with:And this is the place where I get lost and no other forums seem to have an answer. I found a StackOverflow question and its corresponding GitHub issue where the OP claims it worked with a BufferedReader (goodness me), but surely, there should be a more straightforward way, where I declare that I'll handle the entire Request object and either use
BiFunction
with both Request and Response, or just handle the Request and return a String. If my digging is correct than the case with Request$1 means that there is some inheritance going on and the object is private, which is the reason why the cast fails. So now - is this something that can be done, or is this an accepted technical debt, nobody knows how to solve this and thus Spring Cloud Functions do not support and will not support anything else beyond body handling?Thanks a lot, hope my description was clear enough.