Is there a way to remove `implementation ch qos logback logb

Question

Is there a way to remove `implementation ch qos logback logback classic $logback version ` from Ktor 2 0 embededServer it uses reflection and thats bad for `GraalVM native image`

Aleksei Tirman [JB] · Answer

Do you mean from GraalVM sample

Aleksei Tirman [JB] · Answer

As I see `ktor server core` and `ktor server cio` artifacts depend on `logback classic` artifact only in the test source sets

rudolf.hladik · Answer

from `<https github com ktorio ktor samples blob main graalvm build gradle kts>`

rudolf.hladik · Answer

I ve tried comment it out and remove `logback xml` from resources but then it doesn t compile

rudolf.hladik · Answer

I use these deps ```val ktor version = 2 0 0 beta 1 implementation io ktor ktor server content negotiation $ktor version implementation io ktor ktor server core $ktor version implementation io ktor ktor serialization kotlinx json $ktor version implementation io ktor ktor server cio $ktor version ```

rudolf.hladik · Answer

so it should not have dep on logback but the <https mvnrepository com artifact io ktor ktor server core jvm 2 0 0 beta 1> has it

Aleksei Tirman [JB] · Answer

I see only the <https mvnrepository com artifact org slf4j slf4j api|slf4j api> dependency Could you please clarify where did you find it

Aleksei Tirman [JB] · Answer

A native image build is successful when using that sample project ```GraalVM Native Image Generating graal server ======================================================================================================================== 1 7 Initializing 4 6s 0 14GB Version info GraalVM 22 0 0 2 Java 17 CE 1 user provided feature s com oracle svm polyglot kotlin KotlinFeature 2 7 Performing analysis 43 3s 2 13GB 9 073 88 78 of 10 220 classes reachable 13 615 70 94 of 19 192 fields reachable 43 478 55 73 of 78 016 methods reachable 303 classes 103 fields and 738 methods registered for reflection 77 classes 189 fields and 137 methods registered for JNI access 3 7 Building universe 2 6s 2 86GB 4 7 Parsing methods 2 1s 4 00GB 5 7 Inlining methods 3 8s 3 65GB 6 7 Compiling methods 21 5s 1 33GB 7 7 Creating image 4 5s 2 65GB 17 39MB 38 60 for code area 28 223 compilation units 24 55MB 54 48 for image heap 5 876 classes and 348 969 objects 3 12MB 6 93 for other data 45 06MB in total Top 10 packages in code area Top 10 object types in image heap 871 97KB java util 6 62MB byte for general heap data 512 61KB c s org apache xerces internal impl xs traversers 2 86MB java lang String 503 93KB kotlin reflect jvm internal impl metadata 2 34MB byte for java lang String 454 48KB com sun crypto provider 2 23MB java lang Class 445 81KB com sun org apache xerces internal impl 1008 78KB java lang Object 418 84KB java lang 645 35KB java lang String 395 22KB java lang invoke 480 38KB java util HashMap$Node 387 31KB com oracle svm core reflect 473 19KB int 360 95KB sun security x509 343 50KB java util LinkedHashMap 355 56KB com oracle svm jni 340 94KB com oracle svm core util LazyFinalReference 375 additional packages 2067 additional object types use GraalVM Dashboard to see all 7 0s 7 9 of total time in 28 GCs | Peak RSS 6 67GB | CPU load 7 52 Produced artifacts Users Aleksei Tirman projects ktor samples graalvm graal server executable Users Aleksei Tirman projects ktor samples graalvm graal server build artifacts txt``` What error from GraalVM do you get

rudolf.hladik · Answer

you need to remove ` allow incomplete classpath` and ` H +ReportUnsupportedElementsAtRuntime` from `build sh`

Aleksei Tirman [JB] · Answer

Seems like the problem is that the definition of `StaticLoggerBinder` class is located in a logger implementation library According to its <https www slf4j org api org slf4j impl StaticLoggerBinder html|documentation> this class is deprecated and will be removed in the future versions

Aleksei Tirman [JB] · Answer

I ve created <https youtrack jetbrains com issue KTOR 4075|an issue> to address this problem Feel free to add comments with an additional information