Enable Custom Java Arguments for AppCDS Archive Generation

[davidreis97]

Description

While examining the AppCDSBuildStep class, I've noticed a limitation in the current implementation. The process to generate the AppCDS archive does not support the addition of custom Java arguments.

This limitation poses a problem in scenarios like mine, where the AppCDS generation fails due to an attempt to load properties from a Kubernetes ConfigFile, which is not available during the build process.

This enhancement is not only crucial for addressing similar failures but could also be beneficial in various other scenarios where the classes that are loaded depend on java arguments, potentially leading to more optimized AppCDS archives.

Implementation ideas

No response

[quarkus-bot]

/cc @geoand (kubernetes), @iocanel (kubernetes)

[geoand]

Thanks for reporting.

Mind providing a little more information about what exactly fails during the AppCDS build process?

[davidreis97]

Hi @geoand, since my application attempts to load a configuration from a K8s ConfigMap (through quarkus-kubernetes-config), when AppCDS tries to run it with the following command:

/Library/Java/JavaVirtualMachines/jdk-21.0.1.jdk/Contents/Home/bin/java -XX:ArchiveClassesAtExit=app-cds.jsa -Dquarkus.appcds.generate=true -Xlog:cds=debug -jar quarkus-run.jar

It exits with a non-zero exit code due to the following error:

Unable to obtain configuration for ConfigMap objects from Kubernetes API Server

Which makes sense, because I'm not building the AppCDS archive inside of the K8s cluster.

So, I would propose introducing a way to pass java arguments to the command that the AppCDS archive generation runs, so that I could, for example, pass the option -Dquarkus.kubernetes-config.enabled=false.

PS. GitHub automatically added the area/kubernetes label to this issue but that is probably wrong. This is an enhancement suggestion to AppCDS.

[geoand]

Thanks for the info.

So essentially you don't need to add custom flags, you just need the Kubernetes Config extension to not be "active" when AppCDS are built, correct?

[davidreis97]

That would fix my use case, yes, but adding the flags would fix all use cases where a custom java argument might be needed to run the quarkus application 😄

[geoand]

Right, but at this point we don't have such a use case, do we?

[davidreis97]

Consider a use case where a Quarkus application needs to establish connections with external resources (like a database) during runtime, but these resources are not accessible during the build process. In such cases, being able to disable these connections through custom Java arguments at build time would prevent failures and enhance the build process's flexibility and robustness.

But you are correct, in my particular case it's just the Kubernetes ConfigMap dependency that is breaking my process.

[geoand]

Consider a use case where a Quarkus application needs to establish connections with external resources (like a database) during runtime, but these resources are not accessible during the build process. In such cases, being able to disable these connections through custom Java arguments at build time would prevent failures and enhance the build process's flexibility and robustness

These sorts of connections are never started during the AppCDS process generation as Quarkus cuts off the initialization much earler.

But you are correct, in my particular case it's just the Kubernetes ConfigMap dependency that is breaking my process.

👍🏼

[geoand]

#38022 takes care of the problem