Community
Participate
Working Groups
It is possible to specify a destinationFile="" attribute to the <webdoclet ..> task, and probably every annotations task for that matter. Updating the file timestamp of the the target file (e.g. web.xml) should be treated with care, since modified timestamps are used by many containers to auto-detect a change of. I would like to propose that the destinationFile="" attribute is used and it set to a temporary file. When XDoclet completes sucessfully the content of the new temporary file are compared byte for byte with the target. If there is no modification then the temporary file is deleted and the xdoclet run is considered complete. If a modification is detected then an atomic update is performed on the target. This essentially means an overwriting rename is performed (in the case of Unix) or a delete the rename (in the case of Windows). So the window of time where a container may detect a missing file is limited and there is no way the container can end up opening a half written file due to concurrency issues. However you must ensure the temporary file is on the same filesystem/mount point as the target. So ideally your temporary file should have been created inside of the project (not workspace). So this might end up being in $HOME/workspace/MyProject/.settings/tmp/tempfile1239329.tmp The reason for this is that linked projects may exist in the workspace, so the workspace is on a different file system to the project. The crux of this problem is that because the web.xml is updated (unessessarly when you modify your servlet code and XDoclet attributes are in use in it). The server tooling and container both believe the web-app requires a reload, then this most often not the cause, because hot-code replace did the trick.
I have changed it to an enhancement request. It would be nice to have and will revisit the bug when we have some spare time
*** Bug 161189 has been marked as a duplicate of this bug. ***
The duplicate does not seem valid to me. This bug report is expressing concern over updating the timestamp of the web.xml because it was rebuilt by XDoclet but if a byte-to-byte comparison is made between the newly rebuilt web.xml and the one that existed before there was no change made. It was just XDoclet agressively rebuilding the file just in case. Although I do talk of how this feature request could be implmented by using a temporary location I'm not requesting to be able to provide a user definable option. The other bug report Bug 161189 reads to me like the reporter wants to override the destination location XDoclet is using with a user definable option.
Daryl, I am refactoring the bugs into this one so that I can review and resolve them together. I agree that yours is about preventing the regeneration, others are related managing where they are generated. We will do a review of managing the generated sources, so this bug seemed to be a reasonable place to combine this work.
Mass reassignment of bugs from Naci to ejb-inbox.
I am closing all tickets related to XDoclet as WON'T FIX, because there is no committer to support this functionality. I can review patches if anyone is willing to contribute.
