Thank you, Mark! Will do some more research on this and see if I can leverage this.
However, are we still okay refactoring the CorsFilter for extension? Thanks, Amit -----Original Message----- From: Mark Thomas <ma...@apache.org> Sent: Wednesday, September 7, 2022 6:18 AM To: users@tomcat.apache.org Subject: Re: [External] Re: Customizing CorsFilter On 07/09/2022 11:42, Amit Pande wrote: > Could you please share more details on "web.xml" changes and dynamic reload > of applications? Some documentation link or something would be helpful. I > couldn't find anything online. The documentation is rather sparse. See conf/web.xml and look at the nested WatchedResource elements. If a reload of a running application is triggered the following happens: - new requests are allowed but made to wait - existing requests are allowed to complete - the web application is stopped - the web application is started (picking up any new configuration) - any waiting new requests are allowed to proceed By default, any open sessions will be lost. If using the StandardManager you can configure it to persist session across web application (and Tomcat) restarts. > Also, wanted to check with the community - how they handle such a requirement > where the CORS allowed origins can change over time -presumably infrequently > but still. > Manual edit of web.xml and leverage the reload of apps? Or server restart? > What is the best/safe way to edit the main web.xml? Personally, I'd just edit web.xml but I only manage my own very lightly used web applications. Provided you don't have long running requests I'd recommend that approach. For editing web.xml, if you want to be sure use a schema aware XML editor. That should a) ensure it is syntactically correct and b) provide auto-completion options. I normally use an IDE. Mark > > Thanks, > Amit > > -----Original Message----- > From: Mark Thomas <ma...@apache.org> > Sent: Wednesday, September 7, 2022 1:37 AM > To: users@tomcat.apache.org > Subject: [External] Re: Customizing CorsFilter > > > > On 07/09/2022 07:31, Mark Thomas wrote: >> On 06/09/2022 18:42, Amit Pande wrote: >>> Hello all, >>> >>> I am currently using the Tomcat 9.0.65 (9.x) and looking at the >>> possibility of extending the >>> CorsFilter<https://nam12.safelinks.protection.outlook.com/?url=https >>> % >>> 3A%2F%2Ftomcat.apache.org%2Ftomcat-9.0-doc%2Fconfig%2Ffilter.html%23 >>> C >>> ORS_Filter&data=05%7C01%7CAmit.Pande%40veritas.com%7C05dd6e26b66 >>> e >>> 49dcaced08da909b854b%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63 >>> 7 >>> 981294884520628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi >>> V >>> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UVYm >>> M wnGj19cJCuA0Nlc%2Few5SMMGF2nXyJiFasO11hc%3D&reserved=0>, >>> specially the configuration part. >>> >>> I am looking at the ability to initialize the parameters of Tomcat's >>> CorsFilter from a source other than "web.xml" (one under >>> TOMCAT_INSTALL_DIR/conf - so that settings apply for all >>> applications inside this web server). E.g., the configuration could >>> a key-value data store (or a simple property file). >>> >>> Hand-editing the "web.xml" could be calling for trouble if not done >>> carefully. And AFAICT, there isn't any tooling/interface to allow >>> easily and reliably editing the "web.xml". >>> >>> Also, ability to poll the external configuration source allows >>> dynamically reload the CorsFilter configuration without requiring >>> the Tomcat restart. In certain product deployments, web server is >>> just a part and having to restart for some configuration changes to >>> take effect isn't desired, though isn't not a must-have. >>> >>> >>> I was looking for something like: >>> >>> public class CustomCorsFilter extends CorsFilter { >>> >>> @Override >>> public void init() { >>> >>> // load configuration from some other persistence store // >>> initialize fields from super class (which are then used in the >>> actual CORS >>> validation) } >>> >>> @Override >>> public void doFilter(ServletRequest request, ServletResponse >>> response, FilterChain chain) >>> throws IOException, ServletException { >>> super.doFilter(request, response, chain); >>> } >>> >>> } >>> >>> // Additionally, the init can be called periodically which could >>> re-initialize the fields from CorsFilter class. >>> >>> However, currently, the configuration fields are private and there >>> are no setters. >>> >>> Before I explore the option of looking for adding interface to "edit" >>> the web.xml, wanted to check if it's possible to update the >>> CorsFilter and make some methods protected (e.g. >>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi >>> t >>> hub.com%2Fapache%2Ftomcat%2Fblob%2F9.0.65%2Fjava%2Forg%2Fapache%2Fca >>> t >>> alina%2Ffilters%2FCorsFilter.java%23L712&data=05%7C01%7CAmit.Pan >>> d >>> e%40veritas.com%7C05dd6e26b66e49dcaced08da909b854b%7Cfc8e13c0422c4c5 >>> 5 >>> b3eaca318e6cac32%7C0%7C0%7C637981294884520628%7CUnknown%7CTWFpbGZsb3 >>> d >>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% >>> 7 >>> C3000%7C%7C%7C&sdata=SaFrY7oHvHmErLFKaesA55hFPM9o7JiT%2F3M%2BCJ4 >>> s >>> WgY%3D&reserved=0) >>> for extension. >> >> Refactoring the CorsFilter to make it extensible is certainly an option. >> Some things to keep in mind: >> >> - Increasing the visibility of methods is unlikely to be >> controversial >> >> - Getters and setters are preferred to non-private fields >> >> - Any changes need to be backwards compatible >> >> - Supporting dynamic reconfiguration means ensuring that any such >> configuration changes are made in a thread-safe manner. Note that the >> configuration could change in the middle of a request being processed >> by the filter. >> >> That last point is the potentially tricky one. My concern would be >> the performance impacts of any measures taken to ensure thread safety. > > Something that occurred to me just after I pressed send was that Tomcat has a > built-in, general solution to the reconfiguration problem. In a default > configuration, changes to web.xml will trigger a graceful reload of the web > application. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
