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.
