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://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#CORS_Filter>,
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://github.com/apache/tomcat/blob/9.0.65/java/org/apache/catalina/filters/CorsFilter.java#L712)
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
