----- Original Message ----- From: "Vedovato Paolo" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 06, 2004 8:43 AM Subject: RE: [OS-webwork] WW1.3 Memory Consumption
> Hi Dick > > > I just looked briefly at the source. It says you are the > > author, so maybe > > you should know best? :-) > the author? no - just the author of the modifications about the > sorting! the glory about this piece of sw belongs to > Walter Szewelanczyk ;-)) > > Here some good news. Yesterday I could locate the problem! > > It has to do how ComponentTag's doEndTag is processed by the table > tag. I added a fix which prevent this memory growing problem. > I've added my comments inline please have a look and tell > me if the fix makes sense or if we should make the modfications > somewhere else. Please try to tell me this asap because this > fix has to go in production. Hi Paolo, Great that you found the problem. I see now, that when the nameAttr is null it is still looked up on the stack and the current object is returned. Then if the valueAttr is null, BeanUtil.toStringValue is called with the object, which calls the toString method on it, and then VS findValue is called with that string. So the problem you were having occurs when both the name and the value attribute is null. Your fix also affects all cases when the name attribute is null. Before the name parameter would be replaced by the current object on the stack, while now it will be null instead. I do not think other code relies on that dubious feature. So to me your fix looks ok. Cheers, Dick Zetterberg ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
