Il giorno mar 28 dic 2021 alle ore 22:26 Rémy Maucherat <r...@apache.org> ha scritto:
> On Tue, Dec 28, 2021 at 7:18 PM Mar R <marco.robiat...@gmail.com> wrote: > > > > Tomcat 10.0.14 > > Windows 10 x64 21H1 OS Build 19043.1415 > > > > openjdk version "17.0.1" 2021-10-19 > > OpenJDK Runtime Environment GraalVM CE 21.3.0 (build > > 17.0.1+12-jvmci-21.3-b05) > > OpenJDK 64-Bit Server VM GraalVM CE 21.3.0 (build > 17.0.1+12-jvmci-21.3-b05, > > mixed mode, sharing) > > > > NetBeans 12.6, maven webapp project > > Maven 3.8.4 > > Ant 1.10.12 > > > > Followed guide at https://tomcat.apache.org/tomcat-10.0-doc/graal.html > > > > Sorry in advance if not all issues should be reported here but instead > are > > graalvm native image related, I'm reporting everything here and on their > > github fro completeness. > > > > > https://drive.google.com/file/d/17flFW5nlNCdojlvJxCOy23NJBj03p46u/view?usp=sharing > > In this link you can find a folder with everything I used from tomcat > > stuffed folder downloaded from the github link present in the tomcat AOT > > guide, to all commands I put in a script for easier testing purpose, > source > > webapp, built webapp, screenshots, everything :D > > > > I'll start by saying I'm well aware I could definitely have overlooked > > something, anyway I managed to get to the final native image and it > works, > > BUT: > > > > If you remove .class files from webapps/webappname folder, when you run > the > > binary file, it won't find those files, only jsps. This is strange > because > > those files are actually present in the fat jar, and this actually beats > > the purpose of builidng a native image if you have to ship it with java > > files. > > > > If there is a class extending ServletContextListener (InitClass in this > > webapp), when running command with "--catalina -generateCode" parameter, > > where you have to access all jsps and servlets, the class extending > > ServletContextListener will be initialized/used(?) like 2 times, but the > > second time not completly, resetting everything done in the first > > initialization. > > In this webapp it happens when you access the only servlet present. > > Anyway all code is in the google drive link and in InitClass i put some > > prints so you can see what I mean. > > In another bigger webapp my InitClass initializes a lot of things used by > > the webapp basically screwing it. > > This issues happens only in this phase becasue in the second phase where > > the parameter is "useGeneratedCode" it works normally both with this > simple > > test webapp and in my other one > > > > When building with native-image command, if > > "-J--add-exports=java.management/sun.management=ALL-UNNAMED" isn't used > as > > additional parameter, errors will pop on run crashing the app. > (screenshot > > in the google drive link) > > Before looking at it more deeply (later ...), let's take this step by step: > - Even though you are generating a fat JAR and building a native > image, the webapps should stay unchanged. All classes and JARs in > WEB-INF will be needed for annotation scanning and whatever > "classloading". So this is not a bug. Don't worry, regular Java > classes that have not been compiled in a native image are never going > to be magically dynamically loaded and run, since this isn't possible > at all. > - Java 17 with Graal is completely untested (Java 11 is) since it's > very new. Since you seem very adventurous, you can also try to compile > in the Panama support for OpenSSL. > - I haven't tested the JMX support, which is fairly new in Graal. > Adding the module declaration on the command line if needed depending > on the Java version doesn't seem that surprising. If you were running > Java 8 you wouldn't need it. For the longest time, JMX was disabled > with Graal (with no way to enable it). Since it supposedly "works", > the regular Tomcat standalone defaults are used (so you can use the > command line to disable it again; to be honest I would probably do > that ...). > - You can keep your server.xml (more flexible), but once everything > works (if you get there then it's good !) you can indeed generate the > equivalent code for server.xml/context.xml with -generateCode and > avoid some reflection. This is really completely optional. So it seems > there's a problem with ServletContextListener then (this is strange > since it's a web.xml component, for which I never added the actual > code generation - it was tempting but way too complex if the goal was > to support everything). So I'll try to understand what is going on. > > Rémy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -Then to me it seems like it actually beats the purpose of using an embedded solution/native image. Anyway i don't get if the fat jar has ALL the compiled jsps and classes built, why should it ever look for them outside? OR, why annotation scanning isn't done before? so to avoid relying on built files outside fat jar/binary image. -I tested on Java 11 too, will post results after replying to everything. I will try what you suggest but after I manage to solve these issues first, so I can update tutorial page too. -I don't know why you're talking about JMX I'm not using it. If you are referring to "-J--add-exports=java.management/sun.management=ALL-UNNAMED" I just used this because otherwise i couldn't compile, and i even found it while googling by pure luck! So how to remove JMX from entire process? Anyway that parameter isn't need anymore in graal CE 22 (tested the dev builds too) -the server.xml I used is the default one, minus all listener and things commented out as per Tomcat AOT tutorial. About the -generateCode part: I tried a lot looking for some info about this parameter but couldn't find anything. The only page in the internet where it pops up is the Tomcat AOT page linked above and whatever cloned it. I didn't even know if it was Tomcat or GraalVM related until I searched both source code and found it in the Tomcat one :D So could you or someone please explain how it works, I'd like to add those info to the docs too. Now considering I can't edit my first message I'll have to add it here. --- --- --- Tomcat 10.0.14 Windows 10 x64 21H1 OS Build 19043.1415 NetBeans 12.6, maven webapp project Maven 3.8.4 Ant 1.10.12 openjdk version "11.0.13" 2021-10-19 OpenJDK Runtime Environment GraalVM CE 21.3.0 (build 11.0.13+7-jvmci-21.3-b05) OpenJDK 64-Bit Server VM GraalVM CE 21.3.0 (build 11.0.13+7-jvmci-21.3-b05, mixed mode, sharing) openjdk version "17.0.1" 2021-10-19 OpenJDK Runtime Environment GraalVM CE 21.3.0 (build 17.0.1+12-jvmci-21.3-b05) OpenJDK 64-Bit Server VM GraalVM CE 21.3.0 (build 17.0.1+12-jvmci-21.3-b05, mixed mode, sharing) GraalVM CE 22.0.0-dev-20211222_1041 openjdk version "11.0.13" 2021-10-19 OpenJDK Runtime Environment GraalVM CE 22.0.0-dev (build 11.0.13+8-jvmci-22.0-b02) OpenJDK 64-Bit Server VM GraalVM CE 22.0.0-dev (build 11.0.13+8-jvmci-22.0-b02, mixed mode, sharing) GraalVM CE 22.0.0-dev-20211222_1041 openjdk version "17.0.2" 2022-01-18 OpenJDK Runtime Environment GraalVM CE 22.0.0-dev (build 17.0.2+5-jvmci-22.0-b02) OpenJDK 64-Bit Server VM GraalVM CE 22.0.0-dev (build 17.0.2+5-jvmci-22.0-b02, mixed mode, sharing) Followed guide at https://tomcat.apache.org/tomcat-10.0-doc/graal.html Sorry in advance if not all issues should be reported here but instead are tomcat related, I'm reporting everything here and on their mailing list for completeness. https://lists.apache.org/thread/pc0cj9dn9ovxs1qqlqq6p3x88k0jwpmk https://drive.google.com/file/d/1105hPdeA8xqtLfl6QbaI6KTozMJ2bySV/view?usp=sharing https://drive.google.com/file/d/17_JXqNNBZCfCW8-JDl2Kocx0NzEVdc-J/view?usp=sharing In these links you can find a folder with everything I used from tomcat stuffed folder downloaded from the github link present in the tomcat AOT guide, to all commands I put in a script for easier testing purpose, source webapp, built webapp, screenshots for tests with graalvm CE 21.3 java 11 and java 17 all commands/script run as admin. everytime changed JAVA_HOME and graalvm/bin in PATH enviornment variables to reflect actual graalvm used for tests. I'll start by saying I'm well aware I could definitely have overlooked something, anyway I managed to get to the final native image and it works, BUT: 1a) JAVA 11 and 17: If there is a class extending ServletContextListener, when running command with "--catalina -generateCode" parameter, where you have to access all jsps and servlets, the class extending ServletContextListener (InitClass in this example) will be initialized/used(?) like 2 times, but the second time not completly, resetting everything done in the first initialization. 1b) JAVA 11 and 17: if after mvn package run after ant, classes and jsps are removed from webapps/webappname folder, when running command with "--catalina -generateCode" parameter classes aren't found, jsps are. I accessed page.jsp manually on url, it executed it BUT it run InitClass (which is accessed from that jsp) with the already mentioned problem, only static block is initialized. So it's like it is actually able to access compiled classes inside the jar but in a strange way ??!?! -This is strange because those files are actually present in the fat jar, and this actually beats the purpose of builidng a native image if you have to ship it with java files. -If you first run with webapps folder without the webapp and only then copy the BUILT webapp in the folder everything will work correctly, even with ServletContextListener 2a-b) JAVA 11:after -generateCode phase, inside ContextXmlDefault.java "" in paths in watched resources aren't escaped so need to be manually replaced with / or manually escaped else the following mvn package will fail 3a) JAVA 11 and 17: no problems. 3b) JAVA 11 and 17: (after manually escaping/replacing "/", mvn package runs fine for JAVA 11). Same as 1b) 4a-b) JAVA 17: when building with native-image command, if "-J--add-exports=java.management/sun.management=ALL-UNNAMED" isn't used as additional parameter, errors will pop on run crashing the app. 5a) JAVA 11 and 17: no problems. 5b) JAVA 11 and 17: native binary run, with or without parameters, same behaviour as point 1b) Any idea how to fix: The bundle named: org.apache.catalina.tribes.transport.bio.LocalStrings, has not been found. If the bundle is part of a module, verify the bundle name is a fully qualified class name. Otherwise verify the bundle path is accessible in the classpath. The bundle named: org.apache.tomcat.util.threads.res.LocalStrings, has not been found. If the bundle is part of a module, verify the bundle name is a fully qualified class name. Otherwise verify the bundle path is accessible in the classpath.
