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