Hi tomcat external web.xml (in conf/<engine|Catalina>/... typically) is a good one but then if you want a really dynamic solution you will need some code A filter looks good to stay portable but an Authenticator - tomcat API for higher level filters - would allow you to reuse existing authenticators (delegate pattern) and avoid you several code lines.
Depending the app a simple interceptor or JAXRS filter if you use JAXRS 2 are nice API to use for such a need as well. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-11-18 8:24 GMT-08:00 Lars-Fredrik Smedberg <[email protected]>: > Hi! > > I have a possible use-case where I need to have different configurations in > the web.xml depending on the environment deployed to. In the first test > environment I cannot enforce any security constraints, in the other test > environments and in production I would of course like to run with security > on. At the moment we use the security-constraint in the web.xml to make > sure users accessing certain urls has certain roles. > > I got some indications from Anatole who suggested that I would e.g. use a > Filter that depending on some read configurations checks the roles using > the isUserInRole(...) method of the HttpServetlRequest. This would of > course work. > > I also think I saw somewhere that when using Tomcat I could override some > (or all) of the web.xml in the war by placing another web.xml outside the > war in the cataline folder... > > I would however preciate any other ideas to solve the above (in am > application server indendent way if possible). > > The reason for all this is that I would ilke to assemble the war/ear once > and use it throughout testing up to and including the production > environment. > > Best regards > LF > > -- > Med vänlig hälsning / Best regards > > Lars-Fredrik Smedberg > > STATEMENT OF CONFIDENTIALITY: > The information contained in this electronic message and any > attachments to this message are intended for the exclusive use of the > address(es) and may contain confidential or privileged information. If > you are not the intended recipient, please notify Lars-Fredrik Smedberg > immediately at [email protected], and destroy all copies of this > message and any attachments.
