I again forgot something, sorry I spent too much time on this I'm a little tired.
With dev builds, the only difference is that on JAVA 17 there's no need anymore to use -J--add-exports=java.management/sun.management=ALL-UNNAMED and github issues link is https://github.com/oracle/graal/issues/4164 Il giorno ven 31 dic 2021 alle ore 14:47 Mar R <marco.robiat...@gmail.com> ha scritto: > 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. >> >
