Xml-less Tomcat would also be very useful for OSGi http whiteboard implementation which I'd like to work on in the coming months.
So I +1 more programmatic API. Just let's not forget about tear down. So many APIs completely ignore a tear down lifecycle. - Ray On Mon, Jul 20, 2020, 12:16 Romain Manni-Bucau, <rmannibu...@gmail.com> wrote: > I think a xml-less tomcat is awaited since servlet 3 - graal or not - but > agree risk is a bit higher. > That said path is different so wonder if skipping a temp solution can not > be worth after all for the community. > > Le lun. 20 juil. 2020 à 17:58, Filip Hanik <fi...@hanik.com> a écrit : > >> >> On 7/20/20 8:47 AM, Romain Manni-Bucau wrote: >> >> >> >> Le lun. 20 juil. 2020 à 17:41, Filip Hanik <fi...@hanik.com> a écrit : >> >>> Thanks for chiming in: >>> On 7/16/20 6:46 AM, Romain Manni-Bucau wrote: >>> >>> Hi everyone, >>> >>> I think the generation is the sanest option since code stay clean but it >>> shouldn't be done in tomcat IMHO but in user code and with a nice wrapper >>> (mvn tomcat:dump/gradle tomcatDump etc, or whatever name you like ;)). >>> >>> That's always an option, but it would become an external artifact and >>> easily end up out of sync. >>> >> >> Was thinking to keep the dumper in tomcat code base and the plugin to >> consume it so it would stay in sync, but agree it is a small risk. >> >> >>> This build phase would dump the descriptors in plain java and would load >>> them with an unique - ie single for the whole webapp - plain SPI - >>> ServiceLoader - maybe? >>> >>> The goal of this artifact was to reduce the size and classes from a full >>> tomcat (already available in tomcat-embed-core), down to a code base where >>> XML/digester/descriptors aren't used, hence tomcat-embed-programmatic >>> >>> This kind of build tool assumes you have all the runtime state in the >>> build - which is typically the case for graalvm - so you can completely >>> dump StandardContext state after start phase there and just reload it from >>> the precomputed model. >>> Only trick is about file paths which must either be recomputed or be >>> configurable to another base but it does not sound crazy. >>> >>> The less tool-ed option would be to extract all "reflectionfull" code in >>> methods and use graalvm substitutions to drop them and use plain java >>> instead (with a good naming convention, it can be generated as well). >>> Keeps the duplication but at least the main code stays clean and >>> optimizations stays together. >>> >>> That's pretty much what we're doing right now. Many of these feel like >>> hacks simply to mitigate how GraalVM/AOT does code initialization (all code >>> loaded initialized at startup) >>> >> >> Reviewing the hacks, all can be done cleanly if extracted in methods. >> Pushing the logic next step - I don't know if worth it but trying to use >> this picture to explain: >> >> 1. A noxml module can be done with protected methods/extension-points for >> XML loading - even usable in java standalone mode >> 2. Current tomcat can extend noxml module >> 3. Graal can be based on 1 >> >> This would benefit both jvm and graal users at the end. >> Today 1 is possible with some hacks on tomcat embedded but it is highly >> not natural so this can be an opportunity to make it a feature maybe? >> >> I believe that tomcat-embed-programmatic is a viable interim solution, >> it's a low risk. The question for you, and the rest of the community, is >> the reward itself enough? ie, is it worth it? >> >> There is some talk about making "native-ness" part of the Java itself, >> and that could change a lot of assumptions. Making it a feature, >> refactoring code to satisfy 1, is a bit more intrusive at this point in >> time. I believe it introduces more risk than reward. >> >> >> Filip >> >> >> >> >>> Filip >>> >>> >>> >>> 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. 16 juil. 2020 à 14:31, Rémy Maucherat <r...@apache.org> a >>> écrit : >>> >>>> On Mon, Jul 13, 2020 at 11:59 PM Filip Hanik <fha...@vmware.com> wrote: >>>> >>>>> for discussion, all feedback and questions welcome: >>>>> >>>>> >>>>> I've created a concept of having Apache Tomcat, embedded, run without >>>>> reflection in a native image. >>>>> This concept creates a jar, tomcat-embedded-programmatic.jar, that can >>>>> be fine tuned to only include what is needed in a default configuration >>>>> when an embedded tomcat instance is used and configured programatically. >>>>> >>>>> Steps to run Apache Tomcat using Java 8 without reflection >>>>> >>>>> 1. Make sure you have native-image (from the graal installation) >>>>> on your path >>>>> 2. git clone -b feature/embed-minimal-programmatic-jar-file-master >>>>> g...@github.com:fhanik/tomcat.git >>>>> 3. cd tomcat/res/graal/ >>>>> 4. ./build-tomcat-native-image.sh && ./graal-measure.sh >>>>> >>>>> Should yield an output similar to (Graal 20.1): >>>>> SUCCESS: the servlet is working >>>>> RSS memory: 20.7M >>>>> Image size: 20.5M >>>>> >>>>> >>>>> or using an older graal, 19.2 >>>>> SUCCESS: the servlet is working >>>>> RSS memory: 18.0M >>>>> Image size: 16.7M >>>>> >>>>> >>>>> This also leaves a file named ${java.io.tmpdir}/ >>>>> XReflectionIntrospectionUtils.java so that you can review the >>>>> solution to IntrospectionUtils.java >>>>> >>>>> Goals of this concept >>>>> >>>>> 1. Do not break anything >>>>> 2. Create a new and optimized for size artifact, >>>>> tomcat-embedded-programmatic >>>>> 3. Remove reflection by introspecting classes that are currently >>>>> passed into IntrospectionUtils.set/getProperty by generating >>>>> setters/getters at build time >>>>> >>>>> How it's done >>>>> >>>>> 1. I've build out a small introspection tool in the package >>>>> org.apache.tomcat.util.xreflect >>>>> 2. During build time, it analyses a set of known classes that are >>>>> used with IntrospectionUtils.java, and generates >>>>> XReflectionIntrospectionUtils.java >>>>> 3. When it packages tomcat-embed-programmatic.jar it uses the >>>>> generated code when calling setProperty and getProperty >>>>> >>>>> A PR would look like this: >>>>> >>>>> https://github.com/apache/tomcat/compare/master...fhanik:feature/embed-minimal-programmatic-jar-file-master?expand=1 >>>>> >>>>> >>>> Well, this is a bit complex and hard to maintain (like, for example, >>>> storeconfig), so that's a downside. >>>> >>>> So starting with Tomcat and its initial server.xml, the process would >>>> be: >>>> server.xml -> equivalent Tomcat embedded code -> equivalent Tomcat >>>> embedded code with custom IntrospectionUtils code >>>> The concrete benefits may be limited though. >>>> >>>> I looked at more code generation for web.xml since the digester is nice >>>> for that, but the benefit becomes even more questionable. It is harder to >>>> manage, and the generated classes have to be loaded dynamically [unless >>>> even more code is generated]. If there are tons of fragments, there is a >>>> good intuitive reason why it becomes useless. so I didn't want to do it. I >>>> prefer if things remain a bit EE-ish, ultimately. >>>> >>>> Rémy >>>> >>>>
