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 19491 - XML module does not honor node delegates set via info
Summary: XML module does not honor node delegates set via info
Alias: None
Product: xml
Classification: Unclassified
Component: Code (show other bugs)
Version: 3.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: _ pkuzel
: 20792 24659 (view as bug list)
Depends on:
Blocks: 20532
  Show dependency tree
Reported: 2002-01-16 16:50 UTC by Jesse Glick
Modified: 2007-09-25 01:31 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2002-01-16 16:50:51 UTC
[dev jan 16] With the XML module installed, node delegates for XML
files produced via XMLDataObject.Processor or .Environment are not
honored, and the plain XML node is used instead. This breaks
apisupport's layer editing feature and contradicts the API. Please
either do what org.openide.loaders.XMLDataObject does, and use the
supplied node as the object's node delegate, or include that node as a
subnode, etc. Of course for the future this style should be deprecated
in favor of Looks, but that is not yet ready, and older modules using
the existing API ought to be able to work anyway.
Comment 1 _ pkuzel 2002-01-16 16:57:56 UTC
XML module is in similar situation as your modules. Imagine that XML
module also registered an Environment. Who wins? No rules are defined.

Ok, there is a workaround: set netbeans.xml.uselooks=true property (it
is sampled at startup) and then set "Basic" look at XML node. It
should work (sometimes "Basic" look must set twice :-(). If it works
for you then reconsider the P2, please.
Comment 2 Jesse Glick 2002-01-16 17:33:24 UTC
I know the API is not great. Nevertheless no other module *does*
register anything against this DTD, so there is no reason why the API
has to be ignored.

Thanks for the tip, I will try it. If it works I guess I will make
this WONTFIX (if you don't see a reasonable-to-implement workaround in
the XML module), and place that tip on the apisupport release notes
and manual. Could apisupport itself set this system property in
restored(), or would it really need to be done earlier?
Comment 3 _ pkuzel 2002-01-16 17:59:12 UTC
It is sampled to a static field at xml.core.XMLDataObject. I am not
sure if I can guarantee that this class will be loaded after
ApiSupports module installation is performed.
Comment 4 _ lkramolis 2002-01-17 15:55:25 UTC
If workaround does not work, please reopen.
Comment 5 Jesse Glick 2002-01-18 14:55:32 UTC
The workaround works. A little clumsy but enough for now. Thanks.
Comment 6 Martin Schovanek 2002-01-22 11:29:35 UTC
Comment 7 Jesse Glick 2002-03-01 16:51:46 UTC
*** Issue 20792 has been marked as a duplicate of this issue. ***
Comment 8 Martin Entlicher 2002-03-07 14:48:57 UTC
*** Issue 21250 has been marked as a duplicate of this issue. ***
Comment 9 Martin Entlicher 2002-03-07 14:59:10 UTC
It's important for Generic VCS filesystem, which is stored in XML
file. See issue #21250 for details.
As soon as looks become default, it's O.K., but they're not. The same
problem happens in NB 3.3, 3.3.1.
Can this be fixed?
Comment 10 dmladek 2002-03-07 15:42:17 UTC
Thank you Martin for your comment.
CC'ing vcsgeneric bug's list to have ide about progress of this bug
Comment 11 _ lkramolis 2002-03-13 13:52:12 UTC
We will not fix it. Look at Petr's comment (2002-01-16 08:57 PST), it
is as designed. I think, it is wrong design of API in OpenIDE's
XMLDataObject (issue #20792).

You have two possibilities: (1) use Looks feature
(, or (2)
disable XML modules.

XML infrastructure API (issue #20532) is planned to 4.0 release, so
you should decide to solve this in your side, probably by own DataObject.
Comment 12 Martin Entlicher 2002-03-13 16:26:17 UTC
None of these two posibilities are acceptable. Looks are scheduled for
4.0 and I can not force the user to uninstall XML :-(

I don't think I will write a special DataObject just for purpose of
storing FileSystem. This does not make sense to me, the filesystem
should not be forced to do this IMHO. I'll just "wontfix" this.
Comment 13 Jesse Glick 2002-03-20 17:05:20 UTC
Does anyone think this issue is a candidate for the keyword "RELNOTE"? Since it is a 
known loss of functionality affecting at least apisupport module, which will not be 
fixed for 3.3.x, it may deserve a mention in the release notes. I already mention it in 
the apisupport home page and online help, but just to be sure...
Comment 14 Jiri Kovalsky 2002-04-18 07:20:12 UTC
Yes. If you guys can't fix it, I suggest to mention this in Release
Notes since I remember at least two external people that were confused
and asked what does it mean, not counting silent users ... :-)
Comment 15 Martin Schovanek 2002-05-24 16:57:20 UTC
Comment 16 Martin Entlicher 2002-06-12 10:47:12 UTC
*** Issue 24659 has been marked as a duplicate of this issue. ***
Comment 17 Patrick Keegan 2002-07-24 17:03:04 UTC
I'm not sure I have a complete grasp on the user impact, but 
here's a proposed release note. Please provide additions/corrections:

"In order to use the IDE's generic VCS support, API support, or other 
modules that make specialized use of XML in some of their files, you 
might have to disable the IDE's XML modules."
Comment 18 _ pkuzel 2002-07-24 17:31:46 UTC
It is fixed for XMLs at system filesystem.

Martin does it solves your issue? Then no need to mention it in
release notes.
Comment 19 Martin Entlicher 2002-07-24 17:44:03 UTC
Yes, my issue is fixed. From my point of view there is nothing to be
mentioned in the release notes.
Comment 20 Patrick Keegan 2002-07-24 18:08:50 UTC
Thanks. Removing relnote keyword.
Comment 21 Jesse Glick 2002-07-25 18:23:36 UTC
Furthermore for 3.4, apisupport no longer use XMLDO.Info at all. It
creates its own data loader, just like the ant module. So it is
unaffected by the XML modules - they may be on or off.
Comment 22 Quality Engineering 2003-07-02 08:37:50 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.