Error while compiling native image on a vaadin-core dependency


I’m trying to do a native:compile on a Vaadin app and I’m running into the following issue:

 org.apache.commons.logging.LogFactory was unintentionally initialized at build time. To see why org.apache.commons.logging.LogFactory got initialized use --trace-class-initialization=org.apache.commons.logging.LogFactory
org.apache.commons.logging.LogFactoryService was unintentionally initialized at build time. To see why org.apache.commons.logging.LogFactoryService got initialized use --trace-class-initialization=org.apache.commons.logging.LogFactoryService
To see how the classes got initialized, use --trace-class-initialization=org.apache.commons.logging.LogFactory,org.apache.commons.logging.LogFactoryService
Error: Use -H:+ReportExceptionStackTraces to print stacktrace of underlying exception```

I'm quite new to the GraalVM native stuff. In fact, this is the first native:compile I try to do (maybe that answers the question).

I'm asking here, because commons-logging is only pulled in from vaadin-core (through vaadin-core-internal -> flow-server -> httpclient) 

I looked at @secure-leopard 's flow-native example on github to get started. 

Using GraalVM 22.3.0, Vaadin 24.0.5, Spring Boot 3.1.0

Any ideas on how to resolve this? 
I tried a couple of approaches on providing hints on reflection, but not even sure native:compile is picking up the reflect-config.json file I added in META-INF/native-image.

Kind regards,

That’s a new “feature” that started popping up with Spring Boot 3.1.

Add this exclusion to your Vaadin dependency


That should hopefully fix it in most cases

Check this twitter thread for ongoing investigation with the Spring team

Hmmm, OK!

I’ve added the exclusions on both vaadin-core dependency and the dependencyManagement section where I have vaadin-bom.

However, there is still something that’s pulling commons-logging. I see 3 versions being downloaded when I clear it from .m2 cache.

Strange thing is, when I run dependency:tree -Dverbose I don’t see it anywhere.

It’s also possible Maven / Plugins are loading it while you build the app and it’s not included in the final artefact. You can also force spring boot to exclude dependencies from the final runnable jar if you wanna make sure it never lands there

I don’t exactly know why it started complaining about this with 3.1.

After excluding the dependency in my app, I got it working with a normal
mvn -Pproduction -Pnative native:compile

But if I try to run mvn -Pproduction -Pnative spring-boot:build-image, it fails with the same error about the logging :man_shrugging:

@secure-leopard looks like more people have this problem

Yeah, I saw a few other similar tickets

If commons-logging is only used from flow via httpclient4, you can help me promote which would reduce flow’s footprint, get a legacy dependency going away and improve native compatibility at the same time :smirk: * Spring Boot 3.1 also removed support / dependency management for client 4 in favor of 5

Should this just be done :thinking: Doesn’t sound too complicated (didn’t really investigate).

There seems to be some proxy support to make it bit less trivial :grimacing:

Instead of replacing, moving the whole thing to the maven / gradle plugin base would also work I guess :sweat_smile:

That would be optimal, but I guess that might be needed by the dev mode…

Outsider perspective: who is responsible for the NodeJS download / Installation?

  • the dev mode
  • the Plugin

I would go with the second option… and for nothing else this code is used if I trace it correctly :slightly_smiling_face:

nodejs might be needed by dev mode and the plugin. I guess there is an actual dev mode module these days. If so, then the current (flow-server) for sure is the wrong place.

Yeah that was also recently introduced :+1: