You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2013/05/07 14:54:55 UTC
Automatic deployment changes
There have been a few queries [1], [2] recently and there is a long
standard enhancement request [3] regarding automatic deployment.
What has made changes in this area difficult in the past is a) a lack of
a clear definition as to what the expected behaviour is and b) a lack of
test cases to validate that behaviour.
In an attempt to improve the situation, I have tried to document a
proposed expected behaviour [4]. There may be some deviations from the
current behaviour and support for fixing BZ 51294 is new. I hope to
start implementing some test cases for [4] soon. Before I do, any
feedback on the proposed expected behaviour?
I haven't looked in detail at the existing code yet. The proposal may
need tweaking to minimise the deviation from the current behaviour.
Mark
[1] http://markmail.org/thread/pdxtvapqsr7mw7ju
[2] http://tomcat.markmail.org/thread/pf4wbgr7d7zwptcl
[3] https://issues.apache.org/bugzilla/show_bug.cgi?id=51294
[4] http://people.apache.org/~markt/dev/auto-deployment-proposed.txt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Automatic deployment changes
Posted by Mark Thomas <ma...@apache.org>.
On 14/05/2013 20:55, Christopher Schultz wrote:
> On 5/13/13 3:35 AM, Mark Thomas wrote:
>> I've updated the proposal to cover these.
>
> Cool. Having all the rules in one place will be tremendously helpful to
> users. Even if they disagree with the rules, they will at least be
> predictable without having to read the code.
Indeed.
> IIRC, it used to be that Tomcat would unconditionally expand the WAR
> file "for performance reasons". Are those performance reasons no longer
> considered warranted, or has "expandWars" been added so that deployers
> who don't want anything written to the disk can have their way?
unpackWARs has been present for as long as I can remember. Certainly
from Tomcat 4 onwards the intention was that a web app could be a WAR, a
directory or served from anywhere such as a database.
> I'm wondering if a somewhat reasonable change might be to deploy the
> "true" webapp into the work/ directory to resolve these conflicts. So,
> for instance, deploying a WAR file would result in the expansion of the
> WAR file into the work/ directory instead of into webapps/, while
> deployment of a DIR would copy to work/ and serve from there. That way,
> you don't have to worry about potentially killing a DIR when a WAR needs
> to be deployed.
I think that just changes the problem because a user could copy an app
directory and app.war into webapps.
> Of course, that could cause (further?) confusion between the behavior of
> WAR, DIR, and work-DIR for users trying to track-down some obscure
> change they (think they) made and why they can't get it to show up in
> their webapp.
Indeed. We see this when the various anti-resource locking options are used.
I think keeping the process as simple as possible is the way forward,
both for user understanding and simplicity of code.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Automatic deployment changes
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 5/13/13 3:35 AM, Mark Thomas wrote:
> On 08/05/2013 15:18, Christopher Schultz wrote:
>
>> Perhaps I should clarify my question with an example: what happens
>> when a WAR file is found and a DIR also exists with the same
>> context name, but expandWars is false? Does the directory get
>> updated with the contents of the WAR file, or does the WAR's
>> descriptor control the deployment (subject to all the other
>> behavior covered by your table(s)) and then (potentially old)
>> content is served from the pre-existing DIR?
>
> Ah. One of the edge cases that makes this rather more complex than it
> first appears.
>
> There are a couple of ways to get Tomcat into this state. They ways I
> can think of are:
> a) deploy the WAR then copy the DIR
> b) deploy the DIR, stop Tomcat, copy the WAR, start Tomcat
>
> There may be others.
>
> Note for case b) if Tomcat is running, the DIR will be removed.
>
> In both cases what should happen is that the content is served from
> the WAR and the DIR is ignored. The question is what happens when the
> WAR is removed? Is the DIR removed as well? Alternatively, should the
> DIR be removed as soon as it is detected?
>
> I'm leaning towards the DIR just being ignored but a warning logged.
> That would mean:
> - Content is served from the WAR
> - The DIR remains but is unused
> - A warning will be logged when the DIR is first detected
> - If the WAR is removed, the DIR will be deployed
>
> There are similar questions about what happens if you have XML +
> WAR(external) + DIR (expanded) and you add a WAR to the appBase?
> Again, I'm leaning towards ignoring it apart from a warning when it is
> first detected.
>
> I've updated the proposal to cover these.
Cool. Having all the rules in one place will be tremendously helpful to
users. Even if they disagree with the rules, they will at least be
predictable without having to read the code.
IIRC, it used to be that Tomcat would unconditionally expand the WAR
file "for performance reasons". Are those performance reasons no longer
considered warranted, or has "expandWars" been added so that deployers
who don't want anything written to the disk can have their way?
I'm wondering if a somewhat reasonable change might be to deploy the
"true" webapp into the work/ directory to resolve these conflicts. So,
for instance, deploying a WAR file would result in the expansion of the
WAR file into the work/ directory instead of into webapps/, while
deployment of a DIR would copy to work/ and serve from there. That way,
you don't have to worry about potentially killing a DIR when a WAR needs
to be deployed.
Of course, that could cause (further?) confusion between the behavior of
WAR, DIR, and work-DIR for users trying to track-down some obscure
change they (think they) made and why they can't get it to show up in
their webapp.
-chris
Re: Automatic deployment changes
Posted by Mark Thomas <ma...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/05/2013 15:18, Christopher Schultz wrote:
> Perhaps I should clarify my question with an example: what happens
> when a WAR file is found and a DIR also exists with the same
> context name, but expandWars is false? Does the directory get
> updated with the contents of the WAR file, or does the WAR's
> descriptor control the deployment (subject to all the other
> behavior covered by your table(s)) and then (potentially old)
> content is served from the pre-existing DIR?
Ah. One of the edge cases that makes this rather more complex than it
first appears.
There are a couple of ways to get Tomcat into this state. They ways I
can think of are:
a) deploy the WAR then copy the DIR
b) deploy the DIR, stop Tomcat, copy the WAR, start Tomcat
There may be others.
Note for case b) if Tomcat is running, the DIR will be removed.
In both cases what should happen is that the content is served from
the WAR and the DIR is ignored. The question is what happens when the
WAR is removed? Is the DIR removed as well? Alternatively, should the
DIR be removed as soon as it is detected?
I'm leaning towards the DIR just being ignored but a warning logged.
That would mean:
- - Content is served from the WAR
- - The DIR remains but is unused
- - A warning will be logged when the DIR is first detected
- - If the WAR is removed, the DIR will be deployed
There are similar questions about what happens if you have XML +
WAR(external) + DIR (expanded) and you add a WAR to the appBase?
Again, I'm leaning towards ignoring it apart from a warning when it is
first detected.
I've updated the proposal to cover these.
Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRkJfOAAoJEBDAHFovYFnnyLEP/0YfRnWUSY2zq3HTDmDr/s7/
VQZdLJS1A2urUK0yOYPOYufZAwhzA1lqmdOIIG4rQ6755kA3ppjV/Zl2knHduG0N
x0VxF+JYmKVeu9W30vZyXrwAf3zC9PMD6etWCgd8wlOaeedJpnPfiq3vBCMBE8nV
8t0tebNjNEbxm7pJhoyZAvNhQXuiWLP2NpNY91Mxwky2bOLRKUQBKbhUJb5ye+0z
shN4YxG1sOKsjLf58Ktd+4Ur6JwSIyPpOV0c5625N1ihesR1VGAmu31mliwX3EBP
7pKph/BPEBXJTf6IBFmkArAePprPNXbD+NgocZuGeLB0on2KjHNIoeh6GxpSa1F1
3HfUJq1npeGEis051AHngsCqn62xfpQQzLm9CTLJNjug0DXgMxkgzKD99c1cS7GM
11ijfDHykqJfYfcL5pMuW9CfdlNCSFN4jTuAE4MCzCkKBJZ6cod44lN4l/527Xkr
cKDhkE+14r/rHUoCpIPuXh3YeX9F4EH2AN+/P3TAOiATVS8/QZUHWhKltKfqzgRm
x2TrOpbpc81IHSOxvJSxaVNx/0b2rXnd3Ow6cuz52LR8anBMsW0lrVDlvQMPpclA
Tt66Bn8CVxSPQFWccKq2h/twF9HXJih4auGKNiJG7GibmoNGPuTYFyrzB3sy7b1V
4tpkpkZPEs4QrE83Zvu4
=SSAJ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Automatic deployment changes
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 5/7/13 5:05 PM, Mark Thomas wrote:
> On 07/05/2013 21:13, Christopher Schultz wrote:
>> Mark,
>
>> On 5/7/13 8:54 AM, Mark Thomas wrote:
>>> In an attempt to improve the situation, I have tried to document
>>> a proposed expected behaviour [4].
>
>> Cool. Two question:
>
>> 1. What is the difference between "Y/N" and "-" in a column? Y/N
>> seems to mean "does not matter". Does "-" mean "does not apply"? If
>> both WAR=Y and DIR=Y (column headers, not row headers) which takes
>> precedence?
>
> Y/N means the behaviour is the same regardless of how the option is
> configured.
>
> The meaning of '-' varied a little between the tables. I've removed
> them from the first table.
>
> In the second and third tables '-' means "unchanged from not present".
> I could have used N but I wanted to make it clearer what was changing.
>
>> 2. Does the order of your table indicate precedence -- for example,
>> we "prefer" XML to, say, WAR or DIR, right? If so, that indicates
>> that we prefer "WAR" to "DIR"
>
> Yes. The order is always XML, WAR, DIR.
>
>> but above the table you say "If both a WAR and a DIR are available
>> for a web application, Tomcat will serve content from the DIR."
>> which indicates the opposite.
>
> That is strictly for performance reasons when serving content and
> doesn't affect deployment.
Perhaps I should clarify my question with an example: what happens when
a WAR file is found and a DIR also exists with the same context name,
but expandWars is false? Does the directory get updated with the
contents of the WAR file, or does the WAR's descriptor control the
deployment (subject to all the other behavior covered by your table(s))
and then (potentially old) content is served from the pre-existing DIR?
Thanks,
-chris
Re: Automatic deployment changes
Posted by Mark Thomas <ma...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/05/2013 21:13, Christopher Schultz wrote:
> Mark,
>
> On 5/7/13 8:54 AM, Mark Thomas wrote:
>> In an attempt to improve the situation, I have tried to document
>> a proposed expected behaviour [4].
>
> Cool. Two question:
>
> 1. What is the difference between "Y/N" and "-" in a column? Y/N
> seems to mean "does not matter". Does "-" mean "does not apply"? If
> both WAR=Y and DIR=Y (column headers, not row headers) which takes
> precedence?
Y/N means the behaviour is the same regardless of how the option is
configured.
The meaning of '-' varied a little between the tables. I've removed
them from the first table.
In the second and third tables '-' means "unchanged from not present".
I could have used N but I wanted to make it clearer what was changing.
> 2. Does the order of your table indicate precedence -- for example,
> we "prefer" XML to, say, WAR or DIR, right? If so, that indicates
> that we prefer "WAR" to "DIR"
Yes. The order is always XML, WAR, DIR.
> but above the table you say "If both a WAR and a DIR are available
> for a web application, Tomcat will serve content from the DIR."
> which indicates the opposite.
That is strictly for performance reasons when serving content and
doesn't affect deployment.
> Perhaps the rows in the table could be re-ordered to indicate the
> order in which Tomcat checks for those artifacts -- stopping at the
> first one found and processing according to the rules you are
> trying to express.
The columns are already in that order.
I've updated the doc to try and clarify these points.
Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRiWyZAAoJEBDAHFovYFnn5hUP/2zVopqI1lEa35UHiqZQ2/wW
6gpXNM+Run4lImt1MH7EVz0GMPzKUsrR94E0j5I9hL8rxHPBKChLNNE3ZS061VHr
ozjXsepDeBhpJLSDFk61OAsNd8vaqbfR/GfN0g59Fsntd9Ex/qMu0dScXyvnajmD
E7xh8mDbDKaPP83PajXQKYvhUanIzP6aFyCoU1kCZlzzcA7KIA14xkWpca3SbZv7
opkjBN97WtNEQX68vNEYtngyZmcIxlN78/YWctjUvNHFFlTxax2hOHQwuJ3YTfHj
DOKVmxktWZlLL4cRFIXfuRnMDzDjUxeE/UxRbQw7aLfVBb75Xk9HFgtpGy+r7D7q
6fkyAI/JshCONNdzfqXGNgdeUlCXD4LMNVomHfJuz0If6D6HJWqXfogAIsZqSjTu
VxLPUwKkNWDiSiGDKIeNJCvqL+thim/CPE2rwzX19/TxdPcE/+kw0n7vWju9su4w
5mh27OJtatAuhpp7Ww+SKpylGG9DdXugAMJ8YBiy9ePCCqZzjB9acn0T7bU0q25y
KNsDHscoZrRfxFPZ0eUm2fx+/KVcQykXaYyberqGsSy62D6Zlc2VNxGRHWf/59EZ
06nFYBBczz5rLhjTiv9nBPbzhSbEOUDY/WN5bz45NfHAVshpWCqT4v6oLwxMYxNX
cdfqWUNM8405gKZXkdU+
=9vTM
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Automatic deployment changes
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 5/7/13 8:54 AM, Mark Thomas wrote:
> In an attempt to improve the situation, I have tried to document a
> proposed expected behaviour [4].
Cool. Two question:
1. What is the difference between "Y/N" and "-" in a column? Y/N seems
to mean "does not matter". Does "-" mean "does not apply"? If both WAR=Y
and DIR=Y (column headers, not row headers) which takes precedence?
2. Does the order of your table indicate precedence -- for example, we
"prefer" XML to, say, WAR or DIR, right? If so, that indicates that we
prefer "WAR" to "DIR" but above the table you say "If both a WAR and a
DIR are available for a web application, Tomcat will serve content from
the DIR." which indicates the opposite. Perhaps the rows in the table
could be re-ordered to indicate the order in which Tomcat checks for
those artifacts -- stopping at the first one found and processing
according to the rules you are trying to express.
Thanks,
-chris
Re: Automatic deployment changes
Posted by Remy Maucherat <re...@apache.org>.
On Tue, 2013-05-07 at 13:54 +0100, Mark Thomas wrote:
> What has made changes in this area difficult in the past is a) a lack of
> a clear definition as to what the expected behaviour is and b) a lack of
> test cases to validate that behaviour.
a) is very true ...
Anyway, I think it's very good to specify it.
OTOH, the application server I know about uses marker files to expose
the deployment state, allow the user to manage them, and also (perhaps
more importantly) copies the said deployments to an internal location
(something which I obviously chose to avoid at all costs in Tomcat when
I did the deployer hacks). That sort of behavior is a possible option,
but I'm not sure it fits Tomcat well.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Automatic deployment changes
Posted by Mark Thomas <ma...@apache.org>.
On 21/05/2013 23:42, Konstantin Kolinko wrote:
> Finally trying to find some time to review this...
>
> 1) Is there an intent to put [4] into some version-controlled place?
> E.g. webapps/docs/architecture/ ?
>
> Or essentials of it will be included as part of config/context.html ?
> I see some rows from the tables are copied as comments into
> TestHostConfigAutomaticDeployment.java
Yes it will be included somewhere. I'm not exactly sure where yet. I
think some re-organising of the documentation will be required.
> 2) A pair of typos:
>
> s/ content.xml / [appname].xml / (or at least context.xml)
> s/ Redploy / Redeploy /
Thanks. Fixed.
> 3) It is possible to deploy a context by specifying it in server.xml.
>
> I think such a context can be a allowed to reload, but it would be bad
> to autoredeploy it (one should place such webapp outside of appbase).
> What happens with it if ${catalina.base}/conf/context.xml is touched?
I need to do some testing with this.
> 4) I am a bit missing a legend for the tables.
>
> The first table lists what artifacts (XML, WAR, DIR) are present in
> every scenario?
I've tried to clarify it. The order was. Starting point, settings, result.
> 5) There exists "unpackWAR" attribute on a Context, which is not mentioned here.
>
> http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
There are some tests for that. I'm planning on adding an equivalent
context setting for copyXML to address one of the use cases from the
users list.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Automatic deployment changes
Posted by Konstantin Kolinko <kn...@gmail.com>.
2013/5/7 Mark Thomas <ma...@apache.org>:
> There have been a few queries [1], [2] recently and there is a long
> standard enhancement request [3] regarding automatic deployment.
>
> What has made changes in this area difficult in the past is a) a lack of
> a clear definition as to what the expected behaviour is and b) a lack of
> test cases to validate that behaviour.
>
> In an attempt to improve the situation, I have tried to document a
> proposed expected behaviour [4]. There may be some deviations from the
> current behaviour and support for fixing BZ 51294 is new. I hope to
> start implementing some test cases for [4] soon. Before I do, any
> feedback on the proposed expected behaviour?
>
> I haven't looked in detail at the existing code yet. The proposal may
> need tweaking to minimise the deviation from the current behaviour.
>
> Mark
>
>
> [1] http://markmail.org/thread/pdxtvapqsr7mw7ju
> [2] http://tomcat.markmail.org/thread/pf4wbgr7d7zwptcl
> [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=51294
> [4] http://people.apache.org/~markt/dev/auto-deployment-proposed.txt
>
Finally trying to find some time to review this...
1) Is there an intent to put [4] into some version-controlled place?
E.g. webapps/docs/architecture/ ?
Or essentials of it will be included as part of config/context.html ?
I see some rows from the tables are copied as comments into
TestHostConfigAutomaticDeployment.java
2) A pair of typos:
s/ content.xml / [appname].xml / (or at least context.xml)
s/ Redploy / Redeploy /
3) It is possible to deploy a context by specifying it in server.xml.
I think such a context can be a allowed to reload, but it would be bad
to autoredeploy it (one should place such webapp outside of appbase).
What happens with it if ${catalina.base}/conf/context.xml is touched?
As far as I remember from my testing with Tomcat 7, if context that
was defined in server.xml fails to start, the whole Tomcat fails to
start (a Lifecycle exception from starting a child is propagated up
though the call chain).
4) I am a bit missing a legend for the tables.
The first table lists what artifacts (XML, WAR, DIR) are present in
every scenario?
5) There exists "unpackWAR" attribute on a Context, which is not mentioned here.
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org