Community
Participate
Working Groups
While testing bug 103424 I run into a blocking problem with resource modification stamps. After the first update from the source folders, modification stamps for files under .deployables aren't changing, even when the files change (!). This is contrary to the JavaDoc for getModificationStamp() and I haven't seen this behaviour before. The behaviour I'm seeing (with the latest WTP build) is the following: * Deploy a webapp to Tomcat. Start the server, and the State will correctly be Synchronized. * Directly change the web.xml file under .deployables. The modification stamp changes, and the server switches to Restart. * Restart the server, and the State goes back to Synchronized. * Change the regular web.xml file. The web.xml under .deployables get changed, and the modification stamp updated. The server switches back to Restart. * Restart the server, and the State goes back to Synchronized. * Change the regular web.xml file again. The web.xml under .deployables get updated, but the modification stamp never changes! No matter what you do to the file, the modification stamp won't change again until you touch the actual .deployables copy of the file. I have no idea why the .deployables builder wouldn't be triggering the modification stamps to change, since it should be using regular Eclipse APIs to do the copy. This could be an Eclipse resources bug as well. Can we try inserting a touch() or something else to trigger a change just to get past this problem?
Hi Tim - Just curious, what api are you using to get the synch stamp... WorkbenchResourceHelper api's?
Sorry, I'm just using IResource.getModificationStamp(). It is roughly equivalent to java.io.File.lastModified(), except that it only returns a number and not an actual timestamp. The number is supposed to change every time the resource/file is modified, but I am only seeing it change on the first assembly. After that, on subsequent assembles the modification stamp stays the same even though the contents of the file change.
Derek - Can you take a look at this quickly? do we stop copying to .deployables for some reason?
Chuck/Derek - your copy is still working fine, and the files do get updated correctly. The problem is that the modification stamps don't change, fooling anyone who is using them to decide that the files haven't changed. I've heard back from the Web services team, and it sounds like their scenarios are ok for 0.7. Technically, this problem could cause servers to not publish correctly, or to determine that no publish is required even though many files have changed. However, the generic servers do not use this fine-grained support, and the odds of someone hitting this in Tomcat are low. For this reason, I'm going to mark this bug as a P4 and defer past 0.7. We will need to actively (and quickly) resolve this post 0.7 though, since it is a serious issue and will break other server types.
Tim, I've done some playing around and each of your * scenerios the timestamp on disk changes....however, i'm not running a server, just playing around w/ editing the web.xml and building. Could the server code be somehow chaching the resource rather than getting the updated one? Real question is do the windows timestamp changes mean a definite change via the api your using. My guess is yes....if so can you double check the on disk resources is being updated on your workspace?
Just curious ... are Eclpse API's used to do the copy? If so, then sounds like a bug. If direct Java IO is used, then 'refresh' must be called before modification stamp is updated. Right? (Thanks for deferring, though, sounds like a dangerious area to change "last minutes". )
Derek - Yes, disk timestamps are changing, and I am using 'new' IResource handles. The only problem here is that the modification stamp isn't changing even though the contents of the file and everything else is. Even if you were doing an external file copy and a refresh, these stamps would (should) have been automatically updated, so I don't know what is causing this problem.
We'll take a look in m8, but with the publish tasks this might not even be an issue as the builders should go away
This should be resolved by the removal of the .deployables folder and the builder. Defect 97756 *** This bug has been marked as a duplicate of 97756 ***
Closing
