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