On 16.07.2019 19:54, Martynas Jusevičius wrote:
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.
I have not seen your solution. But a question comes to mind : does this not just move the
problem, from tomcat to the Docker container then ?
Why not provide a (shell ? perl ?) installer/updater script, along with the application
WAR, which modifies the application's web.xml (or the server's web.xml) in function of
some site-specific parameter file, which is located somewhere outside the tomcat
directories and remains there ?
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
