Jesse's comment issue 22258
> Petr I suggest a unit test: rename a simple DataObject and confirm
> that PROP_PRIMARY_FILE is *not* fired.

so indeed no PROP_PRIMARY_FILE fired anymore.  I do not have deep
understanding of the DataSystem but the new behavior makes sense.  The
file is the same, it only has a new name.

My wild guess is that the newly corrected behavior of the code exposes
a defect elsewhere.

Added a bunch of people to CC list.  High prio bug.

Hrebejk, please take care of this bug.  Hamernik is on vacation and me
too.  Thanks

New behavior may make sense but we are now in high resistance mode for orion. That 
means it is hard to check all the places that rely on the old behavior. So, in my 
opinion we should go back to the old behavior for orion fcs. Of course I do not know 
what the bug is that was fixed by this change, maybe it is critical.

> New behavior may make sense but we are now in high resistance mode
> for orion.

for the record, phamernik's fix was integrated _before_ high
resistance mode.

Of course if all parties agree that the fix exposes an even more
serious bug elsewhere in the IDE, then rolling back the fix in
netbeans{orion_fcs} branch (not in CVS trunk) is certainly an option.

Andrew, please describe the effects on your modules.  Then QA and
others will consider them and the effects of not fixing issue 22258.
We won't be able to fix both in NB Core because as it seems to me the
defect code is not there.

A related question is: netbeans{orion_fcs} is Sun's branch, we can do
whatever we want, but release33 (== NB 3.3.2) is not ours, not fixing
issue 22258 there looks bad because that bug is real and affects all
users of NB.

Probably the last diff of #22258 could be reversed in orion_fcs for
the benefit of existing buggy code in some modules, without affecting
the reported symptoms of #22258 (which should be cured by the rest of
the patch, specifically the part about item.changePrimaryFile).

I agree with Trung that it is undesirable to rollback any part of
#22258 in release33 branch, however, since AFAIK the patch is correct
and fixes a real bug. If we leave out the last part it should be
considered a special hack to support FFJ modules in this release only.
(And these modules should be listed, together with their reasons to
need the hack.)

OK, tomorrow (Monday) I will look to see what modules might be affected. 

Please do. Try to evaluate the impact on other modules and see if
something is really broken because of this change. The bugfix of
#22258 has been requested by other people working on FFJ and rolling
it back doesn't sound like an option.

I'm changing the version tag to 'FFJ 4.0 ea' and target milestone to
'3.4' to make the bug appear appropriately in the queries. The target
milestone change is not to indicate this is not going to be worked on.
It will be changed when the solution found and a potential bug fix
integrated into the orion_fcs branch.

I tried to look for places where listeners were expecting a 
PROP_PRIMARY_FILE (= "primaryFile") event, and were using this to detect a 
simple rename.  

The comment in DataObject.java says:

 /** Name of primary file property. Primary file is changed when the object is 
moved */
 public static final String PROP_PRIMARY_FILE = "primaryFile"; // NOI18N

so some people may have misinterpreted the meaning of this event.

By inspection, I am a bit suspicious of DBschemaDataObject.

By inspection I thought that the code in JavaDataObject looks OK as it 
listens for changes on PROP_FILES as well as PROP_PRIMARY_FILE.  However 
by partially backing out the DataObject change I was able to make another 
of our closed source bugs go away.  In this bug we have a 
PropertyChangeListener on a ClassElement.  We are looking for a 
ElementProperties.PROP_NAME event.  We hope to see this event when the 
class is renamed.  I think that his event was not being generated with the 
DataObject.java change.  When I backed out the change then we detected the 
rename correctly.  

Unfortunately I haven't had time to prove all my theories :-)

The reason I logged this bug (and did not just fix my code) is that a 
change like this can have unforeseen consequences.  If the change really 
did break ClassElement/JavaDataObject then surely there must be some other 
bits of code which got broken.  

I will track the class rename bug as a separate issue (#22684)

I think Andrew's point is valid. No one knows how many modules
building on 3.3.x are depending on the event being fired. It seems to
me that the most reasonable solution would be the one suggested by
Jesse -- keep the fix of #22258 in place, but rollback the last part
which eliminates firing of the "unnecessary" event.

Unlike Jesse, I wouln't consider this to be a special hack for
orion_fcs. The release33 version of the #22258 bugfix should be
exactly the same. The "correct" version should remain in the trunk only.

Created attachment 5544 [details]
Proposed patch

I've tested the solution proposed by Jesse and it seems to work.
Please see the patch, if everybody agrees I will integrate it.

Sounds OK to me.

Fixed in the orion_fcs branch. The event will still be fired when
renaming DataObject. Please notice that this only applyies to 
versions built on this branch. (Expected id NB 3.3.2 and FFJ 4.0).
This fix is not commited into main trunk i.e. all versions built on
3.4 and later will not fire the PrimaryFileChange on DataObject rename.

verified

Resolved for 3.4.x or earlier, no new info since then -> closing.