You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2016/02/08 22:21:36 UTC
regression due to https://bz.apache.org/bugzilla/show_bug.cgi?id=58867
?
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?
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>
Re: regression due to https://bz.apache.org/bugzilla/show_bug.cgi?id=58867
?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Thanks a lot Mark!
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-10 16:17 GMT+01:00 Mark Thomas <ma...@apache.org>:
> On 09/02/2016 08:29, Mark Thomas wrote:
> > On 09/02/2016 07:33, Romain Manni-Bucau wrote:
> >> 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.
> >
> > Thanks for the additional detail. I was indeed making some invalid
> > assumptions about what the problem was.
> >
> > I'll take a look at this later today.
>
> Sorry for the delay. I got side-tracked.
>
> This is fixed in trunk and 8.0.x and will be in the next release of each
> (in around a month's time).
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: regression due to
https://bz.apache.org/bugzilla/show_bug.cgi?id=58867 ?
Posted by Mark Thomas <ma...@apache.org>.
On 09/02/2016 08:29, Mark Thomas wrote:
> On 09/02/2016 07:33, Romain Manni-Bucau wrote:
>> 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.
>
> Thanks for the additional detail. I was indeed making some invalid
> assumptions about what the problem was.
>
> I'll take a look at this later today.
Sorry for the delay. I got side-tracked.
This is fixed in trunk and 8.0.x and will be in the next release of each
(in around a month's time).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: regression due to
https://bz.apache.org/bugzilla/show_bug.cgi?id=58867 ?
Posted by Mark Thomas <ma...@apache.org>.
On 09/02/2016 07:33, Romain Manni-Bucau wrote:
> 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.
Thanks for the additional detail. I was indeed making some invalid
assumptions about what the problem was.
I'll take a look at this later today.
Mark
>
> 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 <
>> rmannibucau@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: regression due to https://bz.apache.org/bugzilla/show_bug.cgi?id=58867
?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <
> rmannibucau@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: regression due to https://bz.apache.org/bugzilla/show_bug.cgi?id=58867 ?
Posted by Mark Thomas <ma...@apache.org>.
On 8 February 2016 21:21:36 GMT+00:00, Romain Manni-Bucau <rm...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org