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 <[email protected]>:
>
>> On 8 February 2016 21:21:36 GMT+00:00, Romain Manni-Bucau <
>> [email protected]> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
