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. > 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 > > >
