The following comment has been added to this issue:
Author: Darryl Miles
Created: Mon, 9 May 2005 3:11 AM
Body:
It has nothing to do with "deploying" this is purely a building issue, if the
XDoclet process fails for whatever reason deployment will not work anyway. If
this XDoclet process fails and doesn't get as far to writing out the descriptor
then you deploy well you get your "potential for all sorts of bugs" (whatever
that means).
Please take a leaf from how Makefile tasks have been constructed for years, and
how all the compilcation tools chain that work under them are specially
constructed to update the target atomically at the end of a sucessful task.
This is really a 101 issue of basic process design.
What difference it makes:
1) It updates the timestamp on the configuration file, so any timestamp based
automatic rebuilding will not rebuild the (currently corrupted) file, as it now
think that the corrupted file is an up-to-date valid file.
This situation is being used in integrated environments that know which files
have one or more XDoclet tags inside them and it checks the timestamp of those
files (for modifications) against the resulting descriptors to know if XDoclet
needs to be run before automatic (debugging) deployment of your application.
2) It leaves behind a corrupt configuration file. This is a major design
error, either the file should be built correctly or it should delete its
corrupted effort. As anything using it would always expect it to be the
complete article (as all times during its existance).
3) My suggestion of how to update resulting files makes sure that updates
appear atomically to the system, no application will ever see a half built
file, even during the moments XDoclet is executing the write() system calls to
emit the output file.
---------------------------------------------------------------------
View this comment:
http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1388?page=comments#action_16511
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1388
Here is an overview of the issue:
---------------------------------------------------------------------
Key: XDT-1388
Summary: Invalid files left behind after failed build process
Type: Bug
Status: Open
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: XDoclet
Versions:
1.2.3
Assignee: xdoclet-devel (Use for new issues)
Reporter: Darryl Miles
Created: Sat, 7 May 2005 12:35 AM
Updated: Mon, 9 May 2005 3:11 AM
Description:
I think that XDoclet during its building of output files is truncating the
destination file and writing new data directly into it, instead of generateing
the new file as a tmp file in the same dir first then renaming to overwrite.
If an error occurs during the writing process XDoclet seems to just abort where
it is and leave behind a half generated descriptor file.
Bad generation sequence for output.xml:
Open output.xml with O_TRUNC
Read source files writing directly to output.xml
Close output.xml
Good generation sequence for output.xml:
Unlink output.xml.tmp (just in case)
Open output.xml.tmp with O_TRUNC|O_EXCL (any securly generated tmpfile in same
dir will do)
Read source files writing directly to output.xml
Close output.xml.tmp
Rename output.xml.tmp to output.xml
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/xdoclet/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
xdoclet-devel mailing list
xdoclet-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
