Not sure about Tomcat, but what IBM Liberty does is:

It "will" try to redeploy the war when it detects a file change - and it does 
fail naturally since the war isn't complete.

BUT - it will keep trying since during the upload, the timestamp and file size 
automatically keeps changing - so at the end, it will succeed in deploying the 
whole war file.

I wish they would have just monitored the file size for a configurable "given" 
time.  And lets say - if the file size or timestamp doesn't change for -say - 
15 seconds, then go ahead and do the deployment, but as what was mentioned 
earlier, different OS(s) may handle this differently, but the JAVA NIO API 
watchevents point you in the right direction in watching a file/folder in a 
loop for a "create" or "modify" or "delete" event to occur and fire off.


----- Original Message -----
From: "chris" <>
To: "users" <>
Sent: Sunday, February 20, 2022 9:22:17 AM
Subject: Re: <Context … reloadable = "true"> is too quick to respond


On 2/20/22 05:50, John Barrow wrote:
> Neil,
> Thanks for your useful feedback. I am still feeling my way as you can
> probably see from my earlier emails trying to setup a development
> environment.
> I did actually think of this but didn't put it in scope for a couple of 
> reasons.
> Firstly, the Tomcat documentation for readloadable quotes
> "Set to true if you want Catalina to monitor classes in
> /WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically
> reload the web application if a change is detected. This feature is
> very useful during application development, but it requires
> significant runtime overhead and is not recommended for use on
> deployed production applications. That's why the default setting for
> this attribute is false. You can use the Manager web application,
> however, to trigger reloads of deployed applications on demand."
> Therefore, I took it to mean that this flag was geared at development,
> not production which is what I assume when you would deploy a .war
> file. So Tomcat would be listening to specific changes in .classes and
> .jar files that had just been compiled and these are normally small in
> size. But then I suppose that a single .jar file may be so sized that
> Tomcat could react while the file was still being written to the disk.

The patch you are currently working on should fix this aspect of the 
overall problem you are trying to solve.

> Secondly, I sort of assumed that since the feature was already in
> place and handles changes to single files that this check for
> completeness has already been implemented, but then as I can't get a
> development environment to run, I don't have enough skills to drill
> into the sources without it being interactive to help me explore and
> learn.
> However, it makes sense that your recommendation is implemented,
> although I was imagining setting the delay to (say) 500ms to ensure
> that whatever IDE had time to complete the copying of all the files as
> that is a small price to pay for automatic refresh. Also by resetting
> the timer after each event it would have to be quite a large upload
> for Tomcat to start reacting.
> Like you, I am not sure how to formally check that a file has
> completed its copy to the destination. The most common suggestion I
> hear is to try and change its name and then change it back again and
> capture the exception which will be raised if the file is locked. I
> wonder whether attempting to set an attribute (e.g.toggle read-only)
> would have the same effect (i.e. only allow if file wasn't locked) and
> be a little more elegant. I would have to try it.

Don't do anything like that; it won't work on various environments. For 
example, Windows obtains exclusive file-locks for even sometimes 
read-only operations. But *NIX does /not/. So you may develop something 
that works on Windows but doesn't work at all anywhere else.

You basically can't check to see if a file is "done uploading"" or 
whatever else may be happening. What you *can* do is check to see if any 
file in the list-of-files-to-be it *too recent* indicating that a 
compile/copy/upload/whatever may still be in progress.

> I assume that Windows has a way of querying a file lock but not sure
> (a) whether that is exposed via a Java API and (b) whether that would
> apply to Unix as well (as I have only ever used Windows for
> development).
>> How does Tomcat test if a file has been updated?

It's just relative timestamps. Dive into the code Mark suggested and 
you'll find it.

> Again, I don't know this yet (lack of IDE again), but I assumed that
> it would be similar to the method I implemented in the attached source
> code, i.e. Create a listener for events being triggered on file
> changes to either /WEB-INF/classes/ and /WEB-INF/lib, as they are both
> hard-coded file paths.

I don't think your attachment made it to the list. Maybe you can host it 
somewhere else and then post a URL to the list? Attachments tend to be 
stripped. I'm actually surprised your ZIP file made it through.

> As an aside, I should have mentioned, for anyone interested in this
> thread and in case not obvious from the source, but to see the sample
> source code in action, you need to add, modify, rename or delete files
> within the specified directory in a File Explorer.


> On Sun, 20 Feb 2022 at 00:04, Neil Aggarwal <> wrote:
>> John:
>>> If anyone has a moment, can you have a quick look and see if what I am
>>> proposing seems acceptable.
>> Thinking about when a large file (Such as a war file) is being uploaded
>> to the server, we don't want Tomcat to reload it until after the file has
>> completed upload and is fully formed.
>> How does Tomcat test if a file has been updated?
>> I assume it uses File.lastModified() or something similar.
>> Does anyone know the detailed nuts and bolts of how that works?
>> Does last modified keep changing as the file is uploading or is it just
>> changed at the start of the upload?  Is the behavior the same or different
>> across platforms?
>> These questions should be taken into account when designing the solution.
>> Thank you,
>>    Neil
>> --
>> Neil Aggarwal, (972) 834-1565,
>> We offer 30 year loans on single family houses!
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to