I forgot something sorry. Maybe I'm missing something important but, about classloading, on native image shouldn't it NOT exist? As far as I understood after you have a native image you have (resources a part) everything you need inside the binary + libraries, in my case .exe and .dll files. Unless I missed something and a graal native image has a jvm or sort of which will actually run, so now i get why java code outside of the binary will actually be used, BUT then I don't get why it was designed this way, this isn't AOT anymore
Il giorno ven 31 dic 2021 alle ore 14:42 Mar R <marco.robiat...@gmail.com> ha scritto: > 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. >
