On Fri, Dec 31, 2021 at 2:47 PM Mar R <marco.robiat...@gmail.com> wrote: > > 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
Tomcat is a Jakarta EE container, so it does that and runs regular webapps (the main big difference is that the JSPs of the webapp have to be precompiled - luckily this has been a feature for a while). Graal doesn't remove classloading anyway, the webapp initialization is the same, and all components are loaded dynamically from descriptors or annotations. If you don't like that, then you have to look at a framework targeted at making native images. My employer happens to make Quarkus. As for the issues, you should close https://github.com/oracle/graal/issues/4164 I fixed the following issues (will be in the next releases in January): - Packaging some now missing resource bundles (you can ignore warnings like this) - Better escaping for call method rules argument values in generated code (this causes a problem with your Windows paths with the watched resources) I don't understand what you mean about the problem with ServletContextListener. I don't understand why there would be a problem with that. Please try to debug it further if you can. About JMX, Tomcat uses JMX and has it enabled by default. You can disable JMX use in Tomcat with --no-jmx (until recently this was done internally in Tomcat when using AOT). Rémy > > 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. > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
