This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 13612 - JavaDataObject should take a lock before editing the fileobject for package name changes
Summary: JavaDataObject should take a lock before editing the fileobject for package n...
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 3.x
Hardware: All Other
: P3 blocker (vote)
Assignee: issues@java
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-07-13 19:49 UTC by Sadhana Rau
Modified: 2009-10-01 14:51 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
stacktrace (80.32 KB, image/jpeg)
2001-08-22 16:30 UTC, Tomas Hurka 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sadhana Rau 2001-07-13 19:49:08 UTC 
I am tracking a bug where a directory to be renamed contains a checkedin
file. During the investigation I found out that when 
PackageHandler asks the user to change the pkg stmts and then 
JavaDataObject.udpateSource actually changing the pkg stmt, 
it does not take lock before edititng the FileObject.

Lock is taken somewhere along the way, but looks like it is taken 
after the pkg stmt updating step is over.

The reason for that is :

User is asked if user wants to checkout the file. (yes/no)
When user selects yes, the file is checkedout (made writable)
but the pkg stmt is not updated.
Comment 1 Tomas Hurka 2001-08-22 16:28:22 UTC 
Please see attached stacktrace. I think that the lock is taken before
updating package statement. Stacktrace is from current dev build.
Comment 2 Tomas Hurka 2001-08-22 16:30:11 UTC 
Created attachment 2274 [details]
stacktrace
Comment 3 Tomas Hurka 2001-08-29 17:07:36 UTC 
no responce - closing.
Comment 4 Tomas Hurka 2001-08-29 17:09:04 UTC 
no response - closing.
Comment 5 Quality Engineering 2003-07-01 13:11:45 UTC 
Resolved for 3.3.x or earlier, no new info since then -> closing.
Comment 6 Quality Engineering 2003-07-01 13:19:46 UTC 
Resolved for 3.4.x or earlier, no new info since then -> closing.
Comment 7 Marian Mirilovic 2009-10-01 14:48:47 UTC 
reopen to fix status and resolution
Comment 8 Marian Mirilovic 2009-10-01 14:51:21 UTC 
fix status and resolution