DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG� RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=34819>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND� INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34819 ------- Additional Comments From [EMAIL PROTECTED] 2005-05-12 00:48 ------- (In reply to comment #2) > Huh - I enabled debugging output, as described - yet I don't see any more > detailed output I think the issue is that you are passing those params to *ant*, and they aren't being passed through to the code that ant (presumably) executes via a <java> task. The and <java> task can take subtags for passing system properties to the executed code; I suggest you try using those. Or maybe it's the junit libs that are hiding these properties from the code; junit fiddles around with classloaders in order to make the executed tests think they are running in a "clean" VM. Not sure what the effect is on system properties, but I wouldn't be surprised... > >And secondly, could you please write a simple SAX app which attempts to set > >the > >content handler after parsing has started and see what happens? > > I think your right - aelfred pukes on setting the handler when parsing has > started - even if it's setting to the current value - setDTDHandler(this) > > This test case reproduces the problem, I think - > http://www.sfu.ca/~jdbates/tmp/commons-digester/Test.java Well, the issue is setting the *contentHandler*, but if setDTDHandler fails for aelfred, then setContentHandler probably does too. > > But this shouldn't be a difficult fix - is there any reason > reader.setDTDHandler(this) (Digester.java:905) shouldn't depend on the 'if > (reader == null)' (Digester.java:901) clause? No, unfortunately it's quite difficult to fix. Digester creates a parser, then sets *itself* as the content handler for SAX events from that parser (line 895 of Digester.java) so that it can do its work. NodeCreateRule, however, wants to receive the raw SAX events itself, so it temporarily changes the ContentHandler set for that *same* parser object to its own custom content handler. After processing of the node is complete, it sets the ContentHandler back to being the digester instance again. Between these two steps, the digester object is completely inactive; it doesn't get any sax events. In order to handle aelfred, it would be necessary to put a layer of indirection in there somewhere. As it happens, the digester2 code (see subversion repository) handles this case nicely (see the SAXHandler class). It has a field that the user can set to point to a custom handler. Therefore, rather than NodeCreateRule reconfiguring the parser's contenthandler, it sets a member in the digester object to forward calls to itself, and all of digester's SAX callbacks check whether this member is set. eg in the "characters" method of Digester if (customContentHandler != null) { // forward calls instead of handling them here customContentHandler.characters(buffer, start, length); return; } and the same in all the other sax callback methods. If you wished to put together a patch to implement this, I would be happy to review it and commit it (assuming no objections from anyone else). Regards, Simon -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
