Chuck, To avoid repeating myself, please see my reply to Chris, mailed just moments ago.
Yes, I’m considering TomEE as a future option. Dan From: Chuck Caldarale <n82...@gmail.com> Sent: Thursday, August 14, 2025 2:15 AM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: [EXTERNAL EMAIL] How to access a REST service > On 2025 Aug 13, at 23:55, Daniel Schwartz > <d...@danielgschwartz.com<mailto:d...@danielgschwartz.com>> wrote: > > See my > reply below. > > Dan > > From: Chuck Caldarale <n82...@gmail.com > <mailto:n82...@gmail.com<mailto:n82...@gmail.com%20%3cmailto:n82...@gmail.com>>> > > Sent: Wednesday, NkdkJdXPPEBannerStart Be Careful With This Message From (Chuck Caldarale <n82...@gmail.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f604cc39d9bc49bad3f39f6e83e0d9c92c6831319cffe7a8792de1a755759095599f5bf3a6ece3ea0c47a725e80d6f76748181a8c97238dcc42ef76617d9d8c4ef0277948a18fb52f1359b5d3bbdd1d211722bc6197ab41b92485852f77367d1850959bf2506289beaffe2f98b23350e418648499af632bfd89702d4d17e8b4a16211313c511379a59ec7681cbd2cf171807fcee1e2341278ce8d122e34fd9568a969ce1d9e2ff291689a407f404303a2dfc03ee30ed17c13ff78a57a10351dc870757c5341424446a9ec721ed583cb9cec9671d59de4358647226ccee0f9c791779d5aaa9e5ce19f> Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f604cc39d9bc49bad3f39f6e83e0d9c92c6831319cffe7a8792de1a755759095599f5bf3a6ece3ea0c47a725e80d6f76748181a8c97238dcc42ef76617d9d8c4ef0277948a18fb52f1359b5d3bbdd1d211722bc6197ab41b92485852f77367d1850959bf2506289beaffe2f98b23350e418648499af632bfd89702d4d17e8b4a16211313c511379a59ec7681cbd2cf171807fcee1e2341278ce8d122e34fd9568a969ce1d9e2ff291689a407f404303a2dfc03ee30ed17c13ff78a57a10351dc870757c5341424446a9ec721ed583cb9cec9671d59de4358647226ccee0f9c791779d5aaa9e5ce19f> Potential Impersonation The sender's identity could not be verified and someone may be impersonating the sender. Take caution when interacting with this message. NkdkJdXPPEBannerEnd > On 2025 Aug 13, at 23:55, Daniel Schwartz > <d...@danielgschwartz.com<mailto:d...@danielgschwartz.com>> wrote: > > See my reply below. > > Dan > > From: Chuck Caldarale <n82...@gmail.com > <mailto:n82...@gmail.com<mailto:n82...@gmail.com%20%3cmailto:n82...@gmail.com>>> > Sent: Wednesday, August 13, 2025 10:29 PM > To: Tomcat Users List <users@tomcat.apache.org > <mailto:users@tomcat.apache.org<mailto:users@tomcat.apache.org%20%3cmailto:users@tomcat.apache.org>>> > Subject: Re: [EXTERNAL EMAIL] How to access a REST service > > > Uhhh - no. (BTW, the term “program” is rather ambiguous and really has little > meaning in a servlet container environment,) > > Exceptions can also be caught and swallowed, with or without logging them > first. An uncaught exception results in termination of a single thread, not > the entire JVM process (unless it’s the main thread). Tomcat goes to great > lengths to catch any exception that servlet code doesn’t, and returns an > appropriate status to the client that initiated the request that encountered > the exception. Tomcat normally logs exceptions it catches to the webapp’s log > file, not the console (or catalina.out). There has been the rare Tomcat bug > where logging was inadvertently skipped. > > I have no idea what Glassfish does with exceptions, but I would hope that a > simple exception in a servlet running under Glassfish would not result in JVM > termination - that would be really, really stupid and a violation of the > servlet spec. > > Not sure what you mean by “Glassfish quits, not the JVM” - if Glassfish > exits, the JVM process terminates (unless Glassfish is being used in embedded > mode). Do you mean that it’s Glassfish that detects the error and exits > rather than the JVM aborting with, for example, a segfault ("access > violation" in Windows)? > > - Chuck > > > DGS: You are talking above my head on this, but I’m not using any servlets, > and the entire JVM process is the main thread. That’s not possible. Just a “Hello World” program will spawn at least half-a-dozen threads in the JVM. > DGS: Let me put this in context. My system has two components, (1) a backend > REST webservice written in Java and running in Glassfish, (2) a website > written in Next.js that consumes the webservice. The Java program access a > MySql database through the Glassfish pooling system. But this is just an > ordinary Java program running in a single thread. If this throws an > exception that is caught, then the code for the catch clause will output an > error message, and if it throws an exception that is not caught, the JRE will > output a stack trace and terminate. You say that Glassfish will somehow > “swallow” the exception and keep running. I really don’t think so. Maybe > something like this will happen with servlets, but this is just an ordinary > Java program, and this is how Java behaves. It has nothing to do with > Glassfish. Your not using servlets directly is news, and should have been made clear at the beginning of this exceptionally long thread. Is your application really “an ordinary Java program”, or is it dependent on the JAX-RS implementation provided by GlassFish? I strongly suspect the latter, since otherwise there’s no reason for you to use a container like GlassFish. AFAICT, GlassFish uses Jersey to implement JAX-RS (RESTful web services), which generates servlets under the hood. It almost certainly will be using more than one thread, likely creating an instance of your application’s classes for each active client request. If you have any class-level fields you will need synchronization around updates to those. (I believe that was pointed out earlier in this thread.) If you really were able to restrict GlassFish to a single thread, you wouldn’t need DB connection pooling, since a single thread wouldn’t ever need more than connection. GlassFish likely also implements separate logging for each application - even if there’s only one, but I have no idea where those logs would be located. Note that Tomcat does not include support for JAX-RS, so you do need something that implements more of the Jakarta-EE spec, such as TomEE (or GlassFish). - Chuck
