Grigor,

I think this is a use case that Docker containers at least partially
address.

I find deploying containers way easier to share/deploy and more
platform-independent than WAR files.

I’ve created a Tomcat-based image that accepts ENV variables and modifies
server.xml using their values:
https://github.com/AtomGraph/letsencrypt-tomcat

I think you should be able to do the same with web.xml.

Martynas

On Fri, 12 Jul 2019 at 21.44, 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
>
> --
>
>
> *
> *
> *CONFIDENTIALITY NOTE:* THIS E-MAIL MESSAGE AND ANY ATTACHMENTS MAY
> CONTAIN CONFIDENTIAL AND PRIVILEGED INFORMATION OF ONEMARKETDATA, LLC.  IT
> IS FOR THE SOLE USE OF THE INTENDED RECIPIENT(S) AND ANY UNAUTHORIZED
> REVIEW, USE, COPYING OR DISCLOSURE IS PROHIBITED. IF YOU ARE NOT THE
> INTENDED RECIPIENT, PLEASE CONTACT THE SENDER IMMEDIATELY BY REPLY E-MAIL
> OR BY TELEPHONE AT +1 201 710 5977, AND DESTROY ALL COPIES OF THIS MESSAGE
> FROM YOUR SYSTEM.
>
> E-SIGNATURE NOTICE: Unless specifically set forth
> herein, the transmission of this communication is not intended to be a
> legally binding electronic signature, and no offer, commitment or assent
> on
> behalf of OneMarketData, LLC is expressed or implied by the sending of
> this
> email, or any attachments hereto.
>
>

Reply via email to