In my case - I tried on meecrowave - i just switched using Log SPI the impl to something else - custom log4j2 IIRC - and it passed that state until it fails on JMX. Then i @Subtitute some code in the Registry and base classes but it is literally "monkey patching" Tomcat which is something I really disliked - versus adding a module using a SPI which deactivates some potential code path.
My goal is to avoid to fork most of the stack as quarkus did and ensure built-in tomcat can be compiled natively. Using more SPI can be a good option probably and even open more doors to integrators which is never bad IMHO. 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 jeu. 28 mars 2019 à 15:38, Rémy Maucherat <r...@apache.org> a écrit : > On Wed, Mar 20, 2019 at 4:45 PM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > Most of the time monitoring is done through a custom exporter in practise > > based on other impl - sigar, library integration like > > hibernate/eclipselinks ones, metrics, microprofile etc... - and JMX is > not > > then used - not judging it is good, bad, lack of knowledge or not, just > > saying what i see. > > Now I'm happy if JMX is made graal compatible. From what I saw, mainly > the > > MBeanServer and Notifier (through the hierarchy it goes until that point > in > > the JVM in standard mbeans) are blocking the compilation. I'm pretty sure > > these parts of Tomcat can be extracted in a particular class and then > > substrated which would make it graal compatible probably. > > > > Ok, so I had a (quick) look, and this doesn't seem to be something that is > adapted to Tomcat at this time. > > Steps: > - I built the embedded packaging here > https://github.com/apache/tomcat/tree/master/res/tomcat-maven > - It produces a standalone jar in target/tomcat-maven-1.0.jar > - Une the graal tool $GRAALVM/bin/native-image -jar > target/tomcat-maven-1.0.jar > > Produces: > Error: No instances are allowed in the image heap for a class that is > initialized or reinitialized at image runtime: > java.util.logging.SimpleFormatter > Detailed message: > Error: No instances are allowed in the image heap for a class that is > initialized or reinitialized at image runtime: > java.util.logging.SimpleFormatter > Trace: object java.util.logging.ConsoleHandler > object java.lang.Object[] > object java.util.concurrent.CopyOnWriteArrayList > object java.util.logging.LogManager$RootLogger > object java.util.logging.Logger > object org.apache.juli.logging.DirectJDKLog > method > org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleState, > Object, boolean) > Call path from entry point to > org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleState, > Object, boolean): > at > > org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:390) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:193) > at org.apache.catalina.startup.Tomcat.start(Tomcat.java:455) > at org.apache.catalina.startup.Tomcat.main(Tomcat.java:1444) > at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:152) > at > > com.oracle.svm.core.code.IsolateEnterStub.JavaMainWrapper_run_5087f5482cc9a6abc971913ece43acb471d2631b(generated:0) > > If you want to work on this, you can (git makes it easy) but it looks a bit > daunting at this point (java.util.logging is not supported either ? this is > not documented at > https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md ). > > Rémy >
