On July 12, 2019 6:43:49 PM UTC, Grigor Aleksanyan <grigor.aleksan...@onetick.com.INVALID> wrote: >Hi Everyone, > >We have been shipping web application with war packaging in our >production >builds which contains a web.xml with few security sections. >This web.xml defines security constraints that are in most cases not >what >the final deployment uses. This means that to update the war we need to >save new web.xml somewhere, copy the new war, run the server so that it >extracts the war, then shut down the server and copy web.xml back. This >is >a headache for our cloud based web services upgrade as well as in all >other >deployment scenarios, including tests. > >To facilitate deployment we've added a new packaging of another war >file, >which is the same as our original war but its web.xml doesn't contain >any >security sections. >With an empty web.xml (in terms of security), the security can be >defined >via server's conf/web.xml, where it belongs, since the security is in >reality defined by the server rather than the war application. >It would be great if we could just replace our default web.xml but if >some >user uses our default web.xml, they would become unsecured after an >upgrade, so we opted for a separate war. > >Do you guys see any other way of achieving what we aim to achieve with >the >new war file with default web.xml (backwards compatibility is a >constraint >in our case)? >Maybe there is a way of ignoring security sections in the war or we can >make it configurable in the code based on some config/env variable? > >Please let me know if you have any considerations about this, any help >would be appreciated. > >Thank you, >-Grigor
You might be able to do something with the altDDName attribute of the Context element. Generally, though I think folks build deployment specifically WARs with the 'right' configuration. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
