You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Mar R <ma...@gmail.com> on 2021/12/28 18:18:18 UTC
Issues when building native image with GraalVM
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)
Re: Issues when building native image with GraalVM
Posted by Mar R <ma...@gmail.com>.
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 <ma...@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 <ma...@gmail.com>
> ha scritto:
>
>> Il giorno mar 28 dic 2021 alle ore 22:26 Rémy Maucherat <re...@apache.org>
>> ha scritto:
>>
>>> On Tue, Dec 28, 2021 at 7:18 PM Mar R <ma...@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@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.
>>
>
Re: Issues when building native image with GraalVM
Posted by Rémy Maucherat <re...@apache.org>.
On Fri, Jan 7, 2022 at 11:15 PM Mar R <ma...@gmail.com> wrote:
>
> >Tomcat is a Jakarta EE container, [...]
> >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.
>
> Thanks for the suggestion, seems like this will close the gap to a full
> native image that's bothering me :D
Ok, have fun !
> >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.
>
> I don't have any idea how to debug it further, I brought it to the minimum
> possible. It's a new project with just 1 servlet, 1 jsp and 1 class
> implementing ServletContextListener (InitClass.java). I could only leave
> the InitClass but then the issue wouldn't appear because something has to
> access it in some way after it's initialized. So at least a servlet or a
> jsp has to exist and access it.
> As for being an issue, I could be wrong because I don't understand at all
> how the -generateCode and --useGeneratedCode part of the process works. I
> looked a lot but found zero doc/info about those. The only thing I've
> discovered is that those are related to Tomcat (probably about embedding
> Tomcat) and not Graal. (found reference of them in the source code.)
> So I could only suppose: -generateCode generates some kind of code/info
> upon using the webapp, which will be used by -useGenerateCode. Considering
> -useGenerateCode is used alongside the native image agent I suppose the
> previous generated info is needed by the native image agent.
> So, based on these suppositions, I've found it strange that if something
> access a class implementing ServletContextListener after (obviously) it was
> initialized, the webapp workflow goes on like that class didn't even exist.
> To debug this I put a simple System.out.println("<where-I-am>") in the
> static block, in the constructor and in the initializer block. Upon the
> start of the webapp all 3 get correctly run, but once soemthing access that
> class only the static block gets executed and the previous instance gets
> lost. So the effects of whatever code was run before is now lost.
> I don't know how to explain this clearly I'm sorry, the fastest and best
> way would be to try directly, I provided all the code, files, commands I
> used.
Using a static initializer is not the best idea, or at least, it may
need some work on your part:
https://www.graalvm.org/reference-manual/native-image/ClassInitialization/
For example, this class is a big problem for Graal:
https://github.com/apache/tomcat/blob/main/java/org/apache/juli/AsyncFileHandler.java
(this is obviously an extreme example)
-generateCode generates Tomcat embedded code equivalent to your
server.xml (and context.xml files). -useGeneratedCode uses it (after
it is compiled). With Graal this reduces reflection use, but otherwise
has no other benefit so using it is optional. When in doubt, reading
the generated code should help clarify what it does.
> >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).
>
> Thanks I'll try again this way, as soon as I discover where to use it :D
Rémy
> Il giorno mar 4 gen 2022 alle ore 14:22 Rémy Maucherat <re...@apache.org> ha
> scritto:
>
> > On Fri, Dec 31, 2021 at 2:47 PM Mar R <ma...@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.robiati91@gmail.com>
> > > ha scritto:
> > >
> > > > Il giorno mar 28 dic 2021 alle ore 22:26 Rémy Maucherat <
> > remm@apache.org>
> > > > ha scritto:
> > > >
> > > >> On Tue, Dec 28, 2021 at 7:18 PM Mar R <ma...@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-unsubscribe@tomcat.apache.org
> > > >> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issues when building native image with GraalVM
Posted by Mar R <ma...@gmail.com>.
>Tomcat is a Jakarta EE container, [...]
>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.
Thanks for the suggestion, seems like this will close the gap to a full
native image that's bothering me :D
>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.
I don't have any idea how to debug it further, I brought it to the minimum
possible. It's a new project with just 1 servlet, 1 jsp and 1 class
implementing ServletContextListener (InitClass.java). I could only leave
the InitClass but then the issue wouldn't appear because something has to
access it in some way after it's initialized. So at least a servlet or a
jsp has to exist and access it.
As for being an issue, I could be wrong because I don't understand at all
how the -generateCode and --useGeneratedCode part of the process works. I
looked a lot but found zero doc/info about those. The only thing I've
discovered is that those are related to Tomcat (probably about embedding
Tomcat) and not Graal. (found reference of them in the source code.)
So I could only suppose: -generateCode generates some kind of code/info
upon using the webapp, which will be used by -useGenerateCode. Considering
-useGenerateCode is used alongside the native image agent I suppose the
previous generated info is needed by the native image agent.
So, based on these suppositions, I've found it strange that if something
access a class implementing ServletContextListener after (obviously) it was
initialized, the webapp workflow goes on like that class didn't even exist.
To debug this I put a simple System.out.println("<where-I-am>") in the
static block, in the constructor and in the initializer block. Upon the
start of the webapp all 3 get correctly run, but once soemthing access that
class only the static block gets executed and the previous instance gets
lost. So the effects of whatever code was run before is now lost.
I don't know how to explain this clearly I'm sorry, the fastest and best
way would be to try directly, I provided all the code, files, commands I
used.
>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).
Thanks I'll try again this way, as soon as I discover where to use it :D
Il giorno mar 4 gen 2022 alle ore 14:22 Rémy Maucherat <re...@apache.org> ha
scritto:
> On Fri, Dec 31, 2021 at 2:47 PM Mar R <ma...@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.robiati91@gmail.com>
> > ha scritto:
> >
> > > Il giorno mar 28 dic 2021 alle ore 22:26 Rémy Maucherat <
> remm@apache.org>
> > > ha scritto:
> > >
> > >> On Tue, Dec 28, 2021 at 7:18 PM Mar R <ma...@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-unsubscribe@tomcat.apache.org
> > >> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Issues when building native image with GraalVM
Posted by Rémy Maucherat <re...@apache.org>.
On Fri, Dec 31, 2021 at 2:47 PM Mar R <ma...@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 <ma...@gmail.com>
> ha scritto:
>
> > Il giorno mar 28 dic 2021 alle ore 22:26 Rémy Maucherat <re...@apache.org>
> > ha scritto:
> >
> >> On Tue, Dec 28, 2021 at 7:18 PM Mar R <ma...@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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issues when building native image with GraalVM
Posted by Mar R <ma...@gmail.com>.
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 <ma...@gmail.com>
ha scritto:
> Il giorno mar 28 dic 2021 alle ore 22:26 Rémy Maucherat <re...@apache.org>
> ha scritto:
>
>> On Tue, Dec 28, 2021 at 7:18 PM Mar R <ma...@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@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.
>
Re: Issues when building native image with GraalVM
Posted by Mar R <ma...@gmail.com>.
Il giorno mar 28 dic 2021 alle ore 22:26 Rémy Maucherat <re...@apache.org>
ha scritto:
> On Tue, Dec 28, 2021 at 7:18 PM Mar R <ma...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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.
Re: Issues when building native image with GraalVM
Posted by Rémy Maucherat <re...@apache.org>.
On Tue, Dec 28, 2021 at 7:18 PM Mar R <ma...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org