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 20270 - ParseRegen should not depend on DOMParser
Summary: ParseRegen should not depend on DOMParser
Alias: None
Product: obsolete
Classification: Unclassified
Component: apisupport (show other bugs)
Version: 3.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: Jesse Glick
Depends on: 19622 19682 20269 20532
  Show dependency tree
Reported: 2002-02-07 16:07 UTC by Jesse Glick
Modified: 2006-02-14 17:43 UTC (History)
4 users (show)

See Also:
Issue Type: TASK
Exception Reporter:

Patch which does not work: ClassCastException, Crimson's Document impl does not implement EventTarget (3.23 KB, patch)
2002-02-11 16:01 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2002-02-07 16:07:11 UTC
See issue #20269 for more. Copy changes from AntProjectSupport.
Comment 1 Jesse Glick 2002-02-11 15:59:23 UTC
I don't think it can work. If I use XMLUtil to get a DOM parser, it
gives me Crimson. Crimson's Document does not implement EventTarget,
which I need. Xerces' Document does implement the DOM event model, but
of course if the code is to use JAXP and be independent of parser then
I cannot ask for Xerces' parser. What can I do?

Is it really necessary, or just desirable, to remove the dependency on
DOMParser? If xerces.jar will continue to be on the classpath, and it
still contains similar functionality, ant & apisupport could continue
to work while depending on the presence of the Xerces parser. From
what I can see, Xerces 2.0.0 retains the same package naming for the
parser impl. We could get rid of the dep when the TAX API is ready for
outside use.
Comment 2 Jesse Glick 2002-02-11 16:01:05 UTC
Created attachment 4655 [details]
Patch which does not work: ClassCastException, Crimson's Document impl does not implement EventTarget
Comment 3 _ pkuzel 2002-02-11 17:25:20 UTC
DOMParser was not backward compatible in Xerces, last time I tested
Comment 4 Jesse Glick 2002-02-11 19:48:32 UTC
How so? Assuming we compile against Xerces 2.0.0. At least there is a
class with the same name, I didn't check its signature.
Comment 5 _ pkuzel 2002-02-12 09:56:04 UTC
Signatures look good except superclass that matters:

Also I am not sure if xerces will continue to be at classpath. Relying
on classpath proved to be problem as there also lies unknown higher
priority implementations in jre/lib/rt.jar, jre/lib/ext and
Comment 6 Jesse Glick 2002-02-12 12:40:14 UTC
I see your point. In that case I should work on #19622 first so that
ant + apisupport can ask for a private Xerces impl. Hopefully TAX will
mean we will not have to release them in this configuration.

Alternate idea: just like NbSAXParserImpl provides an NB-specific SAX
preference list, maybe we could do the same for DOM parsers. Xerces
seems much more useful for DOM-based apps than Crimson because it has
fuller feature compliance. It is unpleasant to ask JAXP for a DOM
parser with both Crimson and Xerces on the classpath, and to get
Comment 7 _ pkuzel 2002-02-12 14:01:05 UTC
Alternate idea comment: It is addressed by #19682.
Comment 8 Jesse Glick 2002-03-04 10:58:58 UTC
Probably best committed as part of #13904, I guess. The attached patch
should work well enough and leave you free to update the core-supplied
XML libraries.
Comment 9 _ pkuzel 2002-04-26 13:20:29 UTC
You have to use new org.apache.xerces.dom.DocumentImpl(), because
XMLUtil uses JAXP that is configured by core, so it can return
arbitrary DOM implementation selected by core developers.
Comment 10 Jesse Glick 2002-04-26 15:29:26 UTC
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl I guess you mean.
Ought I then declare a package dependency on Xerces packages? I guess
so. Or is there some module which will "provide" Xerces? I have lost
track of what is going on with the parsers...
Comment 11 _ pkuzel 2002-04-26 15:59:48 UTC
It is up to you which approach you choose. Your goal is to get
explicit DOM implementation. It is exactly same as current usage of
new DOMParser(). I works while Xerces2.0.1 is at classpath. To be sure
you need to declare explicit dependecy. Now you have exactly the same
problem as in #20289.
Comment 12 _ pkuzel 2002-04-26 16:01:28 UTC
Sorry #20269 is correct one.
Comment 13 Jesse Glick 2002-05-16 18:15:15 UTC
More or less fixed. The new code first tries to make a
DocumentBuilderFactory using JAXP. It tests it to see if its Document
implementation is assignable to EventTarget. If this fails e.g.
because it is getting Crimson, it tries again by loading the Xerces
impl (using reflection), which will only work if that impl is on the
classpath. If that also fails, layer structure editing will not work.

Note that the Xerces 2.0.1 parser seems to have fixed the lazy node
expansion bug I found in a 1.x parser, but has a new bug which affects
parse-regenerate code and which I can only crudely work around: after
parsing a document with a DOCTYPE, if the included DTD contained any
comments, they appear in the parsed document, between the DOCTYPE and
the root node. Workaround: delete any comments found in this position
immediately after parsing.

committed   * Up-To-Date  1.62        apisupport/
committed   * Up-To-Date  1.13