You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by bu...@apache.org on 2001/02/26 15:58:00 UTC

[Bug 710] New - Custom DocumentImpl not used by parser at runtime

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=710

*** shadow/710	Mon Feb 26 06:58:00 2001
--- shadow/710.tmp.18450	Mon Feb 26 06:58:00 2001
***************
*** 0 ****
--- 1,44 ----
+ +============================================================================+
+ | Custom DocumentImpl not used by parser at runtime                          |
+ +----------------------------------------------------------------------------+
+ |        Bug #: 710                         Product: Xerces-J                |
+ |       Status: NEW                         Version: 1.3.0                   |
+ |   Resolution:                            Platform: All                     |
+ |     Severity: Normal                   OS/Version: All                     |
+ |     Priority: High                      Component: DOM                     |
+ +----------------------------------------------------------------------------+
+ |  Assigned To: xerces-j-dev@xml.apache.org                                  |
+ |  Reported By: osheajohn@eircom.net                                         |
+ +----------------------------------------------------------------------------+
+ |          URL:                                                              |
+ +============================================================================+
+ |                              DESCRIPTION                                   |
+ Problem:
+ ========
+ (The goal is similiar to bug #649 but different results:  I am trying to get 
+ the DOM parser to use a custom DocumentImpl in order to get the parser to 
+ create my subclasses of the defalt ElementImpl used by Xerces - I want to add 
+ in my own business API's to these elements as well as keep track of what's 
+ getting created as the DOM is being built.  ( Sun's ProjectX parser has an 
+ ElementFactory interface which does this well)
+ 
+ Checking the docs, I should be able to do this by:
+ 
+ 1) Write a class that derives from DocumentImpl and override the implementation 
+ of createElement(String tagName)
+ 2) Write a class that extends the DOMParser class and calls setDocumentClassName
+ ("dom.CustomApacheDocumentImpl") on the super class.
+ 3) Parse the document using my Parser "wrapper".
+ 
+ Also, I've noticed a reference to setting the 
+ property "http://apache.org/xml/properties/dom/document-class-name" on the 
+ parser so I'm doing that too in my test client.  I'm not sure why there are two 
+ ways to specify this - perhaps one is being depricated?
+ 
+ In any case, the DOM parser is not using my custom DocumentImpl during the 
+ parse (although it does create one).
+ 
+ Test case is attached - simply compile src/dom/*.java and run 
+ dom.CustomDomTest - you might need to modify the URL location string of the 
+ personal.xml files that are used (they have no other significance, just the 
+ nearest ones to hand when testing:)