Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 21892 - Doing a Refactor.rename doesn't alter list of recently Debug'd class's
Summary: Doing a Refactor.rename doesn't alter list of recently Debug'd class's
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows NT
: P2 enhancement (vote)
Target Milestone: 3.0 M7   Edit
Assignee: Luc Bourlier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 33414 35557 45130 45639 46924 47639 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-07-25 05:56 EDT by Nic Banister CLA
Modified: 2004-02-12 17:35 EST (History)
8 users (show)

See Also:

Attachments
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 Nic Banister CLA 2002-07-25 05:56:13 EDT 
Not sure whether this is really a bug - it may well be intentional, but I 
thought I would report it anyway.

Create a class called Test. Then go to the Debug icon, and select Debug. Set up 
the new class to debug and debug it. Then, obviously, the class's name will 
appear in the list of recently debugged classes.

Then do a Refactor -> Rename and rename the Test class to Test2. All the code 
is change correctly but the old class name of Test still appears in the list. 
Trying to run this, as I thought it then might automatically switch over to 
Test2, throws a ClassNotFoundException.

It may not be a bug (it may be intentional), but i thought it would be clever 
to update the debug settings as well. Otherwise, you have to go in there, and 
rename the class etc etc.

Thanks
Nic
Comment 1 Joe Szurszewski CLA 2002-07-25 15:20:42 EDT 
This is intentional behavior.  We originally considered trying to make launch configurations 
always respond to resource changes (e.g., a launch config for HelloWorld.java deletes itself 
when HelloWorld.java is deleted), but this turned out to impossible to do 100% of the time in the 
Java case, and even worse in the general case for an arbitrary debug model.  The result is that once a 
launch configuration is created, there is no connection between it and the resource it launches 
(assuming it even launches a resource, which was part of the problem).  In the Java case, if you 
rename or delete a resource, you must manually change or delete any associated launch 
configurations.  As always, if you have any insight into this problem, or feel strongly that this 
should be addressed, please comment on this bug report or post to the newsgroup.  For now, I'm 
marking this as WONTFIX.
Comment 2 Nic Banister CLA 2002-07-26 02:59:08 EDT 
Thats fine..its only a minor thing anyway but I thought I would point it out..

Thanks
Comment 3 Darin Wright CLA 2002-07-29 09:21:06 EDT 
There have been several requests/bug reports related to this (i.e. refactoring 
operations should also consider Java launch configurations). I am going to mark 
this bug as "later" since we might consider this an extension to refactoring. 
The refactoring support does not currently support extensions, but there is 
talk of such features in the future (post 2.1).
Comment 4 Darin Wright CLA 2002-07-29 09:21:21 EDT 
Marking as later.
Comment 5 Darin Wright CLA 2003-02-27 09:58:52 EST 
*** Bug 33414 has been marked as a duplicate of this bug. ***
Comment 6 Ilja Preuss CLA 2003-03-03 02:38:24 EST 
A workaround in 2.1 is to select "Update fully qualified name in non Java 
files" and use "*.launch" as file name pattern (as I think about it, it might 
only work on shared launch configurations, though).
Comment 7 Darin Wright CLA 2003-03-24 09:23:31 EST 
*** Bug 35557 has been marked as a duplicate of this bug. ***
Comment 8 Darin Wright CLA 2003-05-14 09:49:38 EDT 
Consider for 3.0.
Comment 9 Darin Wright CLA 2003-10-27 14:14:02 EST 
*** Bug 45130 has been marked as a duplicate of this bug. ***
Comment 10 Darin Wright CLA 2003-10-27 22:15:50 EST 
*** Bug 45639 has been marked as a duplicate of this bug. ***
Comment 11 Darin Wright CLA 2003-11-19 09:43:47 EST 
*** Bug 46924 has been marked as a duplicate of this bug. ***
Comment 12 Darin Wright CLA 2003-11-27 10:33:48 EST 
*** Bug 47639 has been marked as a duplicate of this bug. ***
Comment 13 Luc Bourlier CLA 2004-02-12 17:35:07 EST 
Fixed by the fix for bug 12746.