On Thu, Dec 7, 2017 at 10:51 AM, Mark Thomas <ma...@apache.org> wrote:
> On 07/12/17 09:03, Rémy Maucherat wrote: > > On Wed, Dec 6, 2017 at 8:35 PM, Mark Thomas <ma...@apache.org> wrote: > > > >> On 06/12/17 16:25, Rémy Maucherat wrote: > >>> On Wed, Nov 29, 2017 at 1:12 PM, Mark Thomas <ma...@apache.org> wrote: > >>> > >>>> On 29/11/17 09:46, r...@apache.org wrote: > >>>>> Author: remm > >>>>> Date: Wed Nov 29 09:46:00 2017 > >>>>> New Revision: 1816617 > >>>>> > >>>>> URL: http://svn.apache.org/viewvc?rev=1816617&view=rev > >>>>> Log: > >>>>> Add a bare bones default-context-path impl (best effort really, it's > a > >>>> bad feature). Also fix for some mapping paths, excluded pending some > >>>> clarifications. > >>>> > >>>> I agree that default-context-path is a bad feature. > >>>> > >>> > >>> I still don't see any good way to do this. The Tomcat deployer is > >>> exclusively based on the file name (which isn't bad since you can > change > >> it > >>> - in the context of Tomcat, as you say inside an EAR it's different). > >> From > >>> that the conditions to keep everything in place make the feature > unusable > >>> as far as I am concerned. > >> > >> Just thinking aloud... > >> > >> Could we get the deployer to attempt a rename (if there are no naming > >> conflicts) based on the default-context-path as the very first action > >> and then follow the normal automatic deployment rules? > >> > > > > To be honest, I thought about it, but it seemed quite horrible and didn't > > seem like an acceptable solution to me. Maybe it is then ? > > I hadn't thought much about the implementation detail. The more I think > about it the worse it looks. > > My preference at this point remains not to implement this feature. If > there is demand for it, and an elegant implementation can be found, then > I could live with it. > > We could have another folder, like webapps, where we could say we deploy "enterprise" archives (like if we support some amount of EAR one day, after all it can be used to package multiple wars together), as a way to disguise the predeploy/copy step. Ok, it's horrible too :) Another option is to generate a context file (I'm pretty sure it will have some challenges) while making the original webapp unavailable or something, so the war gets treated as an external one. Rémy
