On 8 February 2016 21:21:36 GMT+00:00, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: >Hi guys, > >in https://bz.apache.org/bugzilla/show_bug.cgi?id=58867 there is this >diff: > >- if (!docDir.exists()) { >- File warFile = new File(docBase + ".war"); >- if (warFile.exists()) { >- URL war = >- new URL("jar:" + warFile.toURI().toURL() + >"!/"); >+ File warFile = new File(docBase + ".war"); >+ URL war = null; >+ if (warFile.exists()) { >+ war = new URL("jar:" + warFile.toURI().toURL() + >"!/"); >+ } >+ if (docDir.exists()) { >+ if (war != null && unpackWARs) { >+ // Check if WAR needs to be re-expanded (e.g. if >it has >+ // changed). Note: HostConfig.deployWar() takes >care of >+ // ensuring that the correct XML file is used. >+ // This will be a NO-OP if the WAR is unchanged. >+ ExpandWar.expand(host, war, pathName); >+ } >+ } else { > > >so if you were deploying a StandardContext with a docDir set to a >correct >path and if the war was next to this path then all was working smoothly >ie >the manually exploded folder was deployed. > >Now (8.0.32) the war is re-expanded in webapps (by default). Of course >a >work around is to set unpackWARs to false but it is a regression in >term of >behavior which is quite nasty IMO. > >Was it really intended or is it a side effect of the fix?
Can you explain the problem more clearly please. Reference to a specific example with file names would help. I can make some assumptions about what I think you are reporting but a clearer explanation would be a better starting point. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
