You can make it supporting JUL switching the log manager to a simpler version, AFAIK this is what quarkus does using jboss logging log manager, guess it shouldn't be that complicated to switch to a lighter version of JUL one without reload capabilities - still thinking out loud.
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 à 16:19, Rémy Maucherat <r...@apache.org> a écrit : > On Thu, Mar 28, 2019 at 3:43 PM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > 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. > > > > Well, support for java.util.logging shouldn't be optional (this isn't even > documented, while JMX is at least documented as not supported). I don't > think Tomcat support is ever going to happen unless Graal capabilities > manages to improve, if at all possible, right now it's simply too alien. > > Rémy >
