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.
Currently if you supply an XMLDataObject.Processor (e.g.) which provides a Node (usually DataNode) for the XMLDO, there is a problem because the node delegate is permanent, and so e.g. reinstalling the module providing the processor does not change the node as it should. So XMLDataObject.createNodeDelegate when a Node is available in the lookup should instead create a FilterNode of the supplied node, and when the lookup changes, use the new setOriginal call to change the delegate (if necessary to a plain XMLNode and maybe back to a custom one). Affects e.g. apisupport's layer nodes. Low-priority since if we get Looks officially in use for XMLDO node delegates, this code would die anyway.
Makes perfect sense. Also the trick how to achive it is smart if such FilterNode's method would exist.
Issue #16434 will need very similar fix. Jesse, should I or you fix it? I am ready to do it because I wrote the core.xml.FileEntityResolver.getLookup (...), so if you want assign both bugs to me. Otherwise assign them to yourself ;-)
I'll assign to you because you said you were working on #16434 anyway, though assign back to me if you don't have time to work on it, or if the fix for this turns out to need fairly different stuff (but they look almost the same I think). Main thing I wouldn't know how to do: figure out exactly when the set of environment processors available for a public ID changes, esp. during module reload. I guess you can listen on changes in the /xml/lookups/ file object, or data object, or InstanceCookie, or something?
Fixed together with issue 16434 FileEntityResolver.java,v rev. 1.9 XMLDataObject.java revision: 1.103
Did you actually try it? It does not work for me. After changing something in apisupport's layer handling--e.g. in WritableXMLFileSystem, change "<root folder>" to "<root folder XXX>"--and reinstall apisupport, not only are existing visible layer nodes not refreshed, but newly recognized and expanded ones still have the subnode "<root folder>" (which may in fact be a regression, at least you used to be able to find "virgin" nodes to try the new XMLDO.P on). Again, assign to me if you like, but this may indicate a bug in the refresh code used for #16434.
Ok, Jesse I would be glad if you can investigate this a bit. My personal suspect is that the problem is in InstaceDataObjectModuleTest5 - .instance data object does not fire PROP_COOKIE change when a module is reinstalled. But you were right, I did not tested the exchange of node because I do not have a testcase.
Target milestone -> 3.3.1.
In [r33 dec 12], in fact some refreshing seems to occur, in that the new code associated with the DTD runs; but it seems that then the new DataNode children are not used: the new nodes have no expand handles nor children. Maybe some other bug? The new DataNode's are really used, as can be seen by fooling around with the displayName. And during the reload, the children appear to disappear and reappear a few times, finally disappearing and staying gone. Seems like XMLDataObject's node delegate code is not working correctly, or perhaps FilterNode is at fault in its handling of children after changing delegate. But sometimes it does work and the children appear. It may be a problem in apisupport, needs to be investigated further (issue #18699 or issue #18700 might be related, not clear).
Well it seems to be working now in [r33 jan 10] in the case of apisupport's layers. I think I was seeing side-effects of #18700, but with that fixed, all appears well. Actually refreshing of XMLDO nodes works a bit *better* than other data nodes: since the node identity does not change (due to use of FilterNode.setOriginal), the Explorer selection is not reset on you if you have one selected.
Resolved for 3.4.x or earlier, no new info since then -> verified
Resolved for 3.4.x or earlier, no new info since then -> closing.