PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2882 *** shadow/2882 Mon Jul 30 09:15:37 2001 --- shadow/2882.tmp.28238 Mon Jul 30 12:24:35 2001 *************** *** 205,207 **** --- 205,228 ---- Thanks for standalone usage clarification. However the reported bug is that SAX processor loads DOM classes, that is suspicuous and time consuming. + + + ------- Additional Comments From [EMAIL PROTECTED] 2001-07-30 12:24 ------- + >However the reported bug is that SAX processor loads DOM classes, that + >is suspicuous and time consuming. + + and the main reason that I didn't invalidate the bug when I added my + comment !! ;-) + + I haven't looked into the issue (1.3.0 is very different than current + versions in this respect), but I suspect that it is a transitive closure + over the implementation problem and not necessarily a design decision + issue. The doctype line is parsed by a class that uses classes that + use classes that use the DOM, and that sort of thing. Were you able to + determine that a DOM document was actually created, or just that the + classes were loaded? If it is once per JVM, it could just be a layering + issue (there are cycles all over the place within Xerces1). Some of + the architectural changes in Xerces2 are meant to overcome many of these + problems, but I don't know of any cases of DOM-less Xerces parser packages. + It could be that the only way to break such dependencies is to introduce + some kind of Class.forName() hook to dynamically reference the DOM code. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
