Le mer. 20 mars 2019 à 15:06, Rémy Maucherat <r...@apache.org> a écrit :
> On Tue, Mar 19, 2019 at 4:52 PM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > Hi Rémy, well there are two topics here: > > > > 1. how to run tomcat without all that JMX stuff - in Meecrowave for > > instance we deactivate it by default since in 80% of the usages it is not > > used - so I think it is a valid option to make it easily deactivable and > if > > done well enough it would be easy to "subtrate" the code through svm > (from > > graal project) which enable to kind of monkey patch an app (so it should > be > > very localized otherwise the maintenance is just hell) > > > > JMX does all the Tomcat monitoring (JVM + container), including also the > monitoring in cloud environments (with Jolokia and Prometheus). So it is > difficult for me to understand why it's a such good idea for users to > remove it. It's quite a bit of work too. > 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. > > > > 2. graalvm will get more and more support for these parts but I guess > > tomcat could be less coupled to JMX - in terms of code path - which would > > also solve the issue. > > > > Finally on the url handler part, it is plain useless in native mode so > > being able to move that URL.setXXX in a static class we would substrate > by > > a noop can be worth it too. > > > > Hope it makes some sense. > > > > Rémy > > > > > 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 mar. 19 mars 2019 à 16:38, Rémy Maucherat <r...@apache.org> a écrit : > > > > > On Sun, Mar 10, 2019 at 6:24 PM Romain Manni-Bucau < > > rmannibu...@gmail.com> > > > wrote: > > > > > > > Hi guys, > > > > > > > > Anyone got a look to graalvm native-image tool? > > > > Tomcat does not work OOTB due to its JMX wide usage - all is not > > > > implemented in graalvm native scope. That said most of this code is > not > > > > really used by Tomcat and can be dropped while keeping Tomcat - at > > least > > > > embedded - running. The other hit issue is the URL handler usage. > > > > > > > > So concretely - and without entering into the details at that early > > > stage, > > > > ensuring TomcatURLStreamHandlerFactory does not use URL custom > factory > > > > registration (constructor) and Registry/MBeanUtils don't rely on > > > > MBeanServer loading directly would be a first step to be able native > > > > images. To test it I @Substitute them with substrate API but it > > requires > > > to > > > > fork some part of Tomcat which is not desired at all on my side. > > > > > > > > This is just the first step since, if you want to keep all features, > > you > > > > will need to create a json with the reflection metadata for some > > features > > > > but at least these two "changes" would enable to run native-image > > > > successfully. > > > > > > > > Overall this mail does not intend to speak of "fix" yet but only > mainly > > > > intend to ask two questions: > > > > > > > > 1. any existing status on graalvm native image support I would have > > > missed? > > > > 2. any will to work in that direction in the community? (graalvm is > > still > > > > very young and lack several features to really embrace java ecosystem > > so > > > > can be fair to say "later") > > > > > > > > > > Well, the said features are quite useful/nice/etc, and I haven't been > > > looking at native images. Any real concrete plan to improve things > > without > > > removing useful items ? > > > > > > Rémy > > > > > >
