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:)