| Summary: | Allow JNDI configuration of CorsFilter | ||
|---|---|---|---|
| Product: | Tomcat 7 | Reporter: | Lucas Theisen <lucastheisen> |
| Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | ||
| Priority: | P2 | ||
| Version: | 7.0.69 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Attachments: | Source code for the delegating filter and integration test. | ||
Moving to an enhancement request. Tomcat typically handles this via property replacement [1]. [1] http://tomcat.apache.org/tomcat-9.0-doc/config/index.html Fair enough... I just find it easier to have all my application config in one place (GlobalNamingResources), rather than multiple (setenv.sh and GlobalNamingResources). In any case, your suggestion would satisfy my requirement to have a single build be configurable differently per environment, so feel free to close this ticket. Closing this ticket as per the OP's comment. It is also worth noting that Java EE allows the injection of values from JNDI into Servlets, Filters etc. See section 5 of the Java EE 8 spec. |
Created attachment 33957 [details] Source code for the delegating filter and integration test. Currently the CorsFilter is configured by init-param's. This makes configuration compile time (as it would be stored in the deployment artifact). In my experience, CORS configuration is environmental (I have a different set of allowed origins based on where I deploy my app: dev/qa/production), and as such should be runtime. Pushing config to JNDI (or at least allowing override in JNDI) allows you to configure the same artifact differently depending on environment. I have written a filter that delegates to the CorsFilter to allow for JNDI config (which i will attach), but it would be quite simple and useful to move this functionality into the core filter. I would be willing to patch the filter as well if you are interested in this approach...