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=29428>. 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=29428 Digester does not keep "root" variable in sync... ------- Additional Comments From [EMAIL PROTECTED] 2004-06-08 22:56 ------- Re the purpose of the "getRoot" method: Stacks don't have roots. Trees have roots. Digester's main purpose is to parse xml and generate a corresponding tree of java objects. And the getRoot method returns the object which is the root of the generated tree. Now that object *might* have been pushed onto the stack before parsing began (in which case it will still be on the stack when parsing finishes), or it may have been created by the first ObjectCreateRule to fire (in which case it will *not* be on the stack when parsing finishes). I guess this could be better explained; I will think about adding some javadoc to the getRoot method. Robert: I still am not sure that a user of Digester would ever have a reason to call clear, nor that there is a reason a Rule class would ever want to. The only reason I can see for this method to have ever existed is to provide "reset-like" behaviour. But it doesn't, and that behaviour is rather nasty to provide correctly [as I found out when I tried]. Can you suggest any situation in which calling clear would have a useful effect other than as preparation for calling parse a second time? I think that "pooling" digester instances is a really bad idea. And not necessary; if a "poolable" RuleSet is created to hold a reusable set of rules, and a "poolable" parser object is created, then the Digester object itself is pretty light-weight to create and configure for each document parsed. Comments? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
