if you add antiJARLocking option to your context tomcat copy the app in temp/ and works on it instead of the one in webapps.
we have this option too (antiJarLocking, think a typo was introduced wanting to copy the tomcat one ;)) wonder if this is activated in the test Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2012/12/8 David Blevins <david.blev...@gmail.com>: > > On Dec 7, 2012, at 12:33 AM, AndyG <andy.gumbre...@orprovision.com> wrote: > >> https://issues.apache.org/jira/browse/OPENEJB-1964 >> > [...] >> What should the process actually be here. Is the real intention to overwrite >> the 'colors' directory with the second deployment? This means the original >> orange.jar is discarded and replaced with the yellow.jar. >> >> Shouldn't the first 'colors' app be undeployed first? > > Seems this is an OS-specfic feature then. The goal is to mimic the Tomcat > webapps/ autoDeploy feature, which allows you to overwrite a deployed archive > and have it redeploy. > > Lame but functional would be to check the "os.name" variable and return early > from the test if on Windows. > > Actually supporting the feature would probably require us to copy the archive > to a tmp dir and deploy the tmp version. I wonder if/how Tomcat supports > this? > > > -David >
