On 07/09/2022 12:22, Amit Pande wrote:
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?
Yes, I am sure the committers will consider any such proposal.
Mark
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
