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 43136 - Properties window of java file node is accidentally closed when property is changed in tests.
Summary: Properties window of java file node is accidentally closed when property is c...
Status: CLOSED WORKSFORME
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 4.x
Hardware: PC Windows XP
: P2 blocker (vote)
Assignee: Jan Pokorsky
URL:
Keywords: T9Y, TEST
Depends on:
Blocks:
 
Reported: 2004-05-12 09:50 UTC by Jiri Skrivanek
Modified: 2007-09-26 09:14 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
stack trace from automated tests (6.46 KB, text/plain)
2004-05-12 09:51 UTC, Jiri Skrivanek
Details
stack trace when manually reproduced (966 bytes, text/plain)
2004-05-12 09:52 UTC, Jiri Skrivanek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Skrivanek 2004-05-12 09:50:34 UTC
IllegalStateException with the following message
is thrown:

Warning - the node "main"
[org.openide.src.nodes.MethodElementNode] is
trying to fire the property body which is not
included in its property sets. This is illegal.
See IZ #31413 for details.

I found it in automated tests when I called
Node.Property.setValue() to rename a java class
(see stackTrace1.txt). The class is renamed but
property sheet is closed and it blocks further
testing.
I found out it is also reproducable manually:

- create a java project with main class
- open the main class
- modify main method and save it (CTRL+S)
- you get exception (see stactTrace2.txt)

Tested in build 20040511-1310, JDK1.4.2_04, WindowsXP.
Comment 1 Jiri Skrivanek 2004-05-12 09:51:09 UTC
Created attachment 14823 [details]
stack trace from automated tests
Comment 2 Jiri Skrivanek 2004-05-12 09:52:19 UTC
Created attachment 14824 [details]
stack trace when manually reproduced
Comment 3 _ tboudreau 2004-05-12 11:14:00 UTC
The diagnostic logging is there to indicate to module owners that they need to fix their 
nodes, because they are firing bogus property changes.  The Java module needs to fix 
their nodes.

It can't be blocking the property sheet, nor can it close it - the exception is logged not 
thrown - it's just coincidence that you're seeing it at the same time.  

How do you *open* the property sheet in these tests, or manually - is it in a separate 
window, or in the main window?

A node firing NodeDestroyed *will* cause a property sheet open in a window to close, but 
nothing has changed about that code in several months, so if there's a problem, it belongs 
to the Java module.

I just tried to reproduce it as I understood the description - open a file, open the property 
sheet on that file, and edit the main method, and could not reproduce the problem - 
probably I don't have a recent enough build.  If it is indeed reproducible, I expect we will 
find that java nodes are firing nodeDestroyed when the file is modified, which is definitely 
a bug.

I'm doing an update, and will try it again.  In the meantime, please let me know exactly 
how you opened the property sheet in question.
Comment 4 _ tboudreau 2004-05-12 11:25:43 UTC
I just tried this on a clean build, opening the properties window for a java file and then 
modifying the file.  No problem (yes the stack trace is posted, but it should be - the java 
module is doing something wrong, and if we don't draw attention to it, they'll never fix it).

Were you opening properties of a method or class node or something?
Comment 5 Jiri Skrivanek 2004-05-12 12:33:05 UTC
The test opens the property sheet in a separate window. Then it tries
to set a new value and the window is closed unintentionally. Manually
only stack trace is reported. It happens for properties of a java
node. So please, reassign to java module if they should fix it.
Comment 6 _ tboudreau 2004-05-12 13:30:16 UTC
Java node as in java file node, java class node or subnode of java class?

Either way, I can't see this being a problem of the property sheet - that code hasn't 
changed.  Re the stack trace, that's WONTFIX - modules need to fix their nodes to only fire 
changes in bean properties they actually have, and not fire the same things to both 
NodeListeners and PropertyChangeListeners.  Probably the java node is firing node 
destroyed when it is renamed.  No idea if that's a bug in the tests, or a bug in the java 
module.  A property sheet in a window will always close if the node is destroyed - it 
doesn't have anything to display anymore.

Please update the subject of this bug to describe the actual problem in the tests - it has 
nothing to do with issue 31413, whatever it is. 
Comment 7 Jan Pokorsky 2004-06-23 15:02:30 UTC
I am also not able to reproduce it neither for java node nor method
node and their property sheets.

JavaNode has never fired nodeDestroyed on rename. It could be caused
by java/srcmode which in case of method rename provided the new
element  and as a consequence of that new node was created.

Since java/srcmodel was replaced with new infrastracture including MDR
this seems to be no more an issue.
Comment 8 Jiri Skrivanek 2004-06-24 07:29:48 UTC
OK, verifiyng.