Re: [EXTERNAL] Re: Embedded vs Standalone Tomcat
Thank you so much Igal for the inputs. Thanks, Amit Thanks, Amit From: Igal Sapir Sent: Sunday, October 18, 2020 11:36:22 AM To: Tomcat Users List Subject: [EXTERNAL] Re: Embedded vs Standalone Tomcat Amit, On Fri, Oct 16, 2020 at 8:32 AM Amit Pande wrote: > My apologies in advance if this has been already discussed in the group. I > am looking for experiences of the community, any nitpicks, etc. > > Currently we are using standalone Tomcat version (9.x) to host a web > applications which are essentially hosting REST APIs. > We plan to move to micro services model where each web application > (logical unit of related APIs) will be hosted as a different process. > > With this mind, I wanted to evaluate the embedded version of Tomcat. > The code for both is the same. The part that we refer to as "Embedded" Tomcat contains most of the implementation. The "Standalone" simply adds a wrapper around the "Embedded" code that allows you to easily run Tomcat using configuration files, startup scripts, service installers, etc. > 1. Is there any guidance around when to use what? > If you have a standard deployment then use "Standalone". If you deploy a different application and Tomcat is used as a component in it, you can consider adding the wrapper and launch code yourself, using the "Embedded" version. If you plan to write a wrapper for "Embedded" that will do exactly what the "Standalone" version does then you will likely spend much resources for no reason, possibly introducing bugs during the process. > 2. Are there any feature disparities between standalone Tomcat and > embedded version? We have fairly extended Tomcat classes for use cases like > automatic certificate renewal, not having to mention is plain-text password > in server.xml for key stores, hooking in custom security provider (for > FIPS) for Tomcat JVM. etc. So we ideally wouldn't want to lose any of such > capabilities when we move to the embedded version. > Same code, I don't see any reason to believe that something would not work as long as the wrapper code that you add to launch the "Embedded" code knows how to utilize those. > 3. Currently, we have written a Windows SCM service wrapper and manage > our Tomcat JVM via that (on Windows). Would there be any issue with > embedded Tomcat if we want to have SCM service wrapper? > Same as above. > 4. How is the upgrade process different for embedded version? > Currently, we ship Tomcat with our product and have a well-defined process > to upgrade Tomcat even with older versions of our product deployed in > customers' environment. > Very similar process - you will have to update the Tomcat JARs and restart the service. As always you will have to check and test that no breaking changes were made in the newer version, though those are rather rare IMO. > 5. Externalizing the configuration (like we can do that via web.xml, > server.xml, context.xml) - any issues, limitations here? > You can set the "Embedded" Tomcat to use the web.xml. If you want to use server.xml and context.xml then you should really revisit question/answer 1) above. > 6. Any differences with resource usages (e.g. heap)? > Nope. It's still a JVM. If you use the same JVM args for both then you should expect similar results. HTH, Igal > > Any help is greatly appreciated. > > Thanks, > Amit > >
Re: Embedded vs Standalone Tomcat
Amit, On Fri, Oct 16, 2020 at 8:32 AM Amit Pande wrote: > My apologies in advance if this has been already discussed in the group. I > am looking for experiences of the community, any nitpicks, etc. > > Currently we are using standalone Tomcat version (9.x) to host a web > applications which are essentially hosting REST APIs. > We plan to move to micro services model where each web application > (logical unit of related APIs) will be hosted as a different process. > > With this mind, I wanted to evaluate the embedded version of Tomcat. > The code for both is the same. The part that we refer to as "Embedded" Tomcat contains most of the implementation. The "Standalone" simply adds a wrapper around the "Embedded" code that allows you to easily run Tomcat using configuration files, startup scripts, service installers, etc. > 1. Is there any guidance around when to use what? > If you have a standard deployment then use "Standalone". If you deploy a different application and Tomcat is used as a component in it, you can consider adding the wrapper and launch code yourself, using the "Embedded" version. If you plan to write a wrapper for "Embedded" that will do exactly what the "Standalone" version does then you will likely spend much resources for no reason, possibly introducing bugs during the process. > 2. Are there any feature disparities between standalone Tomcat and > embedded version? We have fairly extended Tomcat classes for use cases like > automatic certificate renewal, not having to mention is plain-text password > in server.xml for key stores, hooking in custom security provider (for > FIPS) for Tomcat JVM. etc. So we ideally wouldn't want to lose any of such > capabilities when we move to the embedded version. > Same code, I don't see any reason to believe that something would not work as long as the wrapper code that you add to launch the "Embedded" code knows how to utilize those. > 3. Currently, we have written a Windows SCM service wrapper and manage > our Tomcat JVM via that (on Windows). Would there be any issue with > embedded Tomcat if we want to have SCM service wrapper? > Same as above. > 4. How is the upgrade process different for embedded version? > Currently, we ship Tomcat with our product and have a well-defined process > to upgrade Tomcat even with older versions of our product deployed in > customers' environment. > Very similar process - you will have to update the Tomcat JARs and restart the service. As always you will have to check and test that no breaking changes were made in the newer version, though those are rather rare IMO. > 5. Externalizing the configuration (like we can do that via web.xml, > server.xml, context.xml) - any issues, limitations here? > You can set the "Embedded" Tomcat to use the web.xml. If you want to use server.xml and context.xml then you should really revisit question/answer 1) above. > 6. Any differences with resource usages (e.g. heap)? > Nope. It's still a JVM. If you use the same JVM args for both then you should expect similar results. HTH, Igal > > Any help is greatly appreciated. > > Thanks, > Amit > >
Embedded vs Standalone Tomcat
My apologies in advance if this has been already discussed in the group. I am looking for experiences of the community, any nitpicks, etc. Currently we are using standalone Tomcat version (9.x) to host a web applications which are essentially hosting REST APIs. We plan to move to micro services model where each web application (logical unit of related APIs) will be hosted as a different process. With this mind, I wanted to evaluate the embedded version of Tomcat. 1. Is there any guidance around when to use what? 2. Are there any feature disparities between standalone Tomcat and embedded version? We have fairly extended Tomcat classes for use cases like automatic certificate renewal, not having to mention is plain-text password in server.xml for key stores, hooking in custom security provider (for FIPS) for Tomcat JVM. etc. So we ideally wouldn't want to lose any of such capabilities when we move to the embedded version. 3. Currently, we have written a Windows SCM service wrapper and manage our Tomcat JVM via that (on Windows). Would there be any issue with embedded Tomcat if we want to have SCM service wrapper? 4. How is the upgrade process different for embedded version? Currently, we ship Tomcat with our product and have a well-defined process to upgrade Tomcat even with older versions of our product deployed in customers' environment. 5. Externalizing the configuration (like we can do that via web.xml, server.xml, context.xml) - any issues, limitations here? 6. Any differences with resource usages (e.g. heap)? Any help is greatly appreciated. Thanks, Amit
