Hi mark,
if you put a war in a specific folder then expand it yourself next to the
war and do something like:
StandardContext ctx = new StandardContext();
// several set
ctx.setDocBase("/my/expanded/"); // /my/expanded.war exists since that's
where we come from
host.addChild(ctx);
then you get a duplicated deployment with autodeploy settings and unpackWAR
set to true. It sounds like the wrong behavior to me since the auto deploy
doesnt apply to /my/ folder but ${tomcat.base}/webapps - by default.
Tomcat class does it for instance, TomEE does it too and fixed it
preventing unpacking and several tools around tomcat as well. I guess - can
check if needed - a plain tomcat installation can get it setting an
absolute docBase on <Context /> .
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>
2016-02-09 1:35 GMT+01:00 Mark Thomas <ma...@apache.org>:
> 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
>
>
