any test case?  A pointer to your code (use private emails)?

Not data loss -> P2

*** Issue 31431 has been marked as a duplicate of this issue. ***

Stranger still, *some* nodes in options work correctly, and some do
not.  For example:

Options | Code Documentation | Documentation - open a bunch of
properties windows on it, and changing one property causes all of
the other windows to update.

Options | Debugging & Executing | JSP & Servlets Settings - multiple
property windows do not update.

This suggests to me that the problem is somewhere in nodes, not
in property sheet per-se, but I'll keep digging.

There seem to be two independent problems here.

I added some logging to PropertySheetTab and a couple other places,
to see if property changes were being received.  For all
nodes the the listener is attached correctly.  For SOME nodes
(for example, JSP settings) no change is fired - this seems to be a 
problem in nodes.  I added logging of the underlying node class
(by making FilterNode.getOriginal public), but found no mapping
between what the underlying class is and a node not firing changes.

For OTHER nodes (for example, Beans Property), change ARE fired
correctly, but the PropertySheetTab does not recognize the property
name as being a key in its cache of PropertyModel objects, so it 
does nothing.

So: The property sheet code is working correctly, but something has 
changed in the way some nodes fire property changes in the last few days.

And: The property sheet tab code is (?) not working quite correctly,
but *nothing* has changed recently in that code that could affect
it.

Adding Jirka Rechtacek to the cc list, and hoping somebody knows
what changed with regards to changes being fired from settings 
nodes.

The problem is not in property sheet.  See the log below -
the property name, for example, is initially "gen_indexed" - 
but when the property change is fired, the property name is
"genIndexed".

This does not answer the question of why some nodes (like
JSP settings) do not fire any changes at all, but it's likely
the same change caused both behaviors.

Tab got property change: gen_indexed from
org.netbeans.core.projects.SettingChildren$SettingFilterNode@1ddff76[Name=Beans
Property, displayName=Beans Property]
Property gen_indexed not in model cache - do nothing
CACHE
CONTENTS:genIndexed,genBound,genConstrained,genAccess,propStyle,useInherit,
Tab got property change: gen_indexed from
org.netbeans.core.projects.SettingChildren$SettingFilterNode@1ddff76[Name=Beans
Property, displayName=Beans Property]
Property gen_indexed not in model cache - do nothing
CACHE
CONTENTS:genIndexed,genBound,genConstrained,genAccess,propStyle,useInherit,

Created attachment 9137 [details]
Logging code for PropertySheetTab - may be useful for diagnosis (you need to make FilterNode.getOriginal() public and rebuild openide to use)

The problem that the JSP node does not fire changes is a JSP debugger
issue. I suggest to create the new bug for them.

Yes, it looks like web core, beans module and junit all have their
own bugs.  I will file bugs for them.

Jesse suggests a unit test which traverses all options nodes, changes
values and tries to set them, then checks for a property change and
checks that the property name is correct.  Not a bad idea.

The JSP module is not
firing any changes from its settings node;  the beans and junit
modules do not use JavaBeans conventions for names.  The property
sheet depends on the following contract - that property.getName()
shall be the same as propertyChangeEvent.getPropertyName().  
Otherwise it assumes that it is not displaying the property which is
firing changes.

I am closing this issue as invalid.  If you can reproduce it
with a node which fires changes with valid property names when
it is supposed to, please reopen.

Sent email to Trung and Petr Hrebejk with instructions
on how to reproduce running latest S1S EE build.

This issue is not resolved. I have sent email to
Trung and Petr Hrebejk on how to reproduce when
running the latest S1S EE build.

Joe is correct.  My apologies for closing this prematurely -  it led 
me to find bugs in other places, and I jumped to conclusions.

I will attach a test node which reproduces the problem.  Run it 
with Test Beans execution, display its properties, right click it
and choose Add a Property from the context menu.  The new property
does not appear.

Created attachment 9144 [details]
A simple node with an action to add properties to it

On second thought...

In my few-days-old dev build, it does not work.

In the current trunk it works perfectly.  Joe, please do a CVS
update of openide and see if your module is now working correctly as well.

When I was doing some diagnostics to try and solve this issue,
I eliminated an unnecessary use of WeakListener in the
propertysheet (explicity adding/removing it on addNotify()/
removeNotify() instead).  Since it did not leak
and made the code more efficient, I committed this change.
It may have solved the problem.  If so, let me know.

Sorry for the confusion and thanks - this issue led to the 
identification of others.

Got following scenario from Joe per email. - Tested in today's
S1S build and it works.

* Run S1S

* Create a package

* Create a Message-Driven EJB.
  * From the package pop up menu, select "New->All Templates".
  * Expand J2EE node
  * Select "Message-Driven EJB"
  * Select "Next"
  * Take all defaults, select "Finish"
  * In explorer, you will now have two nodes:
    * MessageDriven (EJB)
    * MessageDrivenBean (java file)
    
* Select the EJB node if it isn't selected

* Property sheet will display properties for the EJB

* Change "Transaction Type" property from Container to Bean

* At this point, a new property named "Acknowledge Mode" should
  appear on the property sheet. It does not. (Prior to building
  S1S on top of the latest Q build, it would appear).
  
* Select a different node in the explorer.

* Select the MessageDriven (EJB) node again. Note that the
  Acknowledge Mode property is displayed.

I just did a build of S1S using the NB trunk rather than
the last promoted Q build and this bug is fixed.

This issue is referenced by diagnostics message:

java.lang.IllegalStateException: Warning - the
node $NODE$ is
trying to fire the property $NAME$ which is not
included in its property sets. This is illegal.
See IZ #31413 for details.

Suggested fix is to bulk event firing for non Node.PropertySet properties:

     void superPropertyChange (String name, Object o, Object n) {
+        if (hasPropertyChangeListener()) {
+            if (name == null || findPropertyNames().contains(name)) {
         super.firePropertyChange (name, o, n);
+            }
+        }
+    }
+
+    /**
+     * finds all names of node's properties
+     * @return
+     */
+    private Set findPropertyNames() {
+        Set names = new HashSet();
+        Node.PropertySet[] npsets = getPropertySets();
+        for (int i = 0; i < npsets.length; i++) {
+            Node.PropertySet npset = npsets[i];
+            Node.Property[] nps = npset.getProperties();
+            for (int j = 0; j < nps.length; j++) {
+                Node.Property np = nps[j];
+                names.add(np.getName());
+            }
+        }
+        return names;
+    }
+
+    public Node.PropertySet[] getPropertySets() {
+        return super.getPropertySets();
     }


The diagnostic message and suggested patch seems to be requesting
nonsence. Original problem here are missing events. So why code must
not fire extra property change event for non declared (bound to
visualization) properties?

Please clarify.

Just do not fire property changes of properties which are not in the
property sheet. The propertyChenge listener in node should be used
exclusively for property sheet properties not for any properties of
the node itself.

bad resolution

x

closed