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%23C
ORS_Filter&data=05%7C01%7CAmit.Pande%40veritas.com%7C05dd6e26b66e
49dcaced08da909b854b%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637
981294884520628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UVYmM
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%2Fgit
hub.com%2Fapache%2Ftomcat%2Fblob%2F9.0.65%2Fjava%2Forg%2Fapache%2Fcat
alina%2Ffilters%2FCorsFilter.java%23L712&data=05%7C01%7CAmit.Pand
e%40veritas.com%7C05dd6e26b66e49dcaced08da909b854b%7Cfc8e13c0422c4c55
b3eaca318e6cac32%7C0%7C0%7C637981294884520628%7CUnknown%7CTWFpbGZsb3d
8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
C3000%7C%7C%7C&sdata=SaFrY7oHvHmErLFKaesA55hFPM9o7JiT%2F3M%2BCJ4s
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
