Depending the reflection usage you can generate a feature registering all the classes for reflections, is it predicble and "generable" at build time? Can lead to a "a bit too big" metadata space but nothing crazy.
here what i used in manual mode for a sample (if it helps): https://github.com/rmannibucau/docosh/blob/broken-graal-threadlocal/src/main/java/com/github/rmannibucau/docker/compose/cli/svm/Feature_Reflections.java#L35 Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 26 avr. 2019 à 11:42, Rémy Maucherat <r...@apache.org> a écrit : > On Thu, Apr 25, 2019 at 3:07 PM Rémy Maucherat <r...@apache.org> wrote: > > > On Wed, Apr 24, 2019 at 6:29 PM Romain Manni-Bucau < > rmannibu...@gmail.com> > > wrote: > > > >> Awesome news Rémy, thanks for sharing! > >> > > > > Next roadblock is https://github.com/oracle/graal/issues/684 > > It's probably not 100% mandatory but I'd rather have a minimum of > > flexibility (I'm not a big believer of Java only embedding since > > configuration can get complex fast and it's harder to maintain long > term). > > > > Feel free to help if you'd like. > > > > Ok, so after configuring reflection to some extent in order to examine the > behavior, I am now rather confident things might work out eventually. > I thought the best strategy was to add tracing to Tomcat and have the user > do a regular run with its config to generate the reflection json. In the > end, I found that there's a tool to do that already in graal, in the form > of a jvm agent. I then ran into > https://github.com/oracle/graal/issues/1194 > (exact same crash trace), not sure about any workaround so I'll wait for > the issue to be resolved in a future RC. > > Rémy >
