Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 152120

Summary:	[xdoclet] XDoclet should take care to not update the target unless its actually changed
Product:	[WebTools] WTP EJB Tools	Reporter:	Darryl Miles <darryl>
Component:	jst.ejb	Assignee:	jst.ejb <jst.ejb-inbox>
Status:	RESOLVED WONTFIX	QA Contact:	Kaloyan Raev <kaloyan>
Severity:	enhancement
Priority:	P4	CC:	eric.lewis, kaloyan
Version:	1.5	Keywords:	helpwanted
Target Milestone:	Future
Hardware:	PC
OS:	Linux
Whiteboard:

Description Darryl Miles

2006-07-28 06:22:08 EDT

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.

Comment 1 Naci Dai

2006-07-28 11:14:35 EDT

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

Comment 2 Naci Dai

2007-04-02 01:27:03 EDT

*** Bug 161189 has been marked as a duplicate of this bug. ***

Comment 3 Darryl Miles

2007-04-02 13:03:09 EDT

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.

Comment 4 Naci Dai

2007-04-03 11:52:47 EDT

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.

Comment 5 Kaloyan Raev

2008-04-09 03:30:55 EDT

Mass reassignment of bugs from Naci to ejb-inbox.

Comment 6 Kaloyan Raev

2012-11-02 03:39:36 EDT

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.