I wanted to give a little status on this and query the committers on how they would like me to proceed.
I've finished the changes for this, but I haven't checked anything in, as the consensus was that we wanted to delay a fix for this until after 1.1. The change "simply" required making sure every attribute of every tag was represented by an instance variable of the ELTag class (all suffixed with "Expr"), along with associated getters and setters for each attribute. The BeanInfo class maps each plain attribute name to the "set<attr>Expr()" setter method. In the "evaluateExpressions()" methods, it calls "get<attr>Expr()" to get the current expression value, evaluates the expression through the EL engine, and calls "set<attr>()" on the result. Although the number of lines changed and added represent a huge percentage of the existing code, all of these changes were very straightforward. So straightforward that I performed most of the changes with an Emacs Elisp script. With this setup, even if the setter method associated with the attribute is only called once (because the container saw it using a "static" value), the correct value will be retrieved inside the "doStartTag()" call, to evaluate the expression in the context of the reused tag. Again, the fault with the previous code is that many of the getter methods associated with the tag attributes were set to use the base class getter method. If the setter method wasn't called again to set the EL expression, the value pulled out of the getter would be the evaluated value, not the expression. With this change, the expression string is preserved so it could be used when the tag handler is reused. I've run through my existing Cactus tests, and I've manually displayed all the pages in the strutsel-exercise-taglib. I have ONLY used Tomcat 4.1.10 and 4.1.18 for my testing, and neither the Cactus tests or the exercise taglib tests every aspect of the library. In fact, the Cactus tests don't test all of the tags, and neither does the exercise taglib. Nevertheless, based on my understanding of the problem and the change I've made, I'm reasonably confident this will work in Resin, or any other container that takes advantage of this optimization defined in the JSP specification. I don't know of any other containers besides Resin that uses this optimization. I asked about this on one of the WebLogic newsgroups, but I haven't gotten a response yet. Along the way, I discovered another problem that caused me to remove a line of code from every expression evaluation. When expressions are evaluated, if the attribute expression was null, it causes a call to "set<attr>(null)". This caused problems in cases where an unset attribute in a base class has a non-null default value (like the "name" attribute in several tags). I fixed this by removing the call to "set<attr>(null)" if the expression was null. I realized this could be more efficient, by just not evaluating it if the expression was null. I'll look at enhancing that in a later release. Again, I've finished these changes and done some testing, but I don't have Resin or other containers installed to test on any other containers. I'd like to make this fix available for the 1.1 release, but I admit there's some risk involved. Even worse, tomorrow morning (Sunday) I'm going out of town until very late Friday evening. I won't be able to check my email until somewhat late on Saturday morning. As a risk mitigation strategy, is it reasonable/practical to tag all the current versions of the files in the struts-el directory with a label like "BEFORE_ATTR_FIX"? If I do commit these changes and they create unexpected problems, "someone" might be able to back up the versions to that tag. Also, if I do commit these changes, I'd like to know if someone, especially including the person who reported the problem with Resin (perhaps unlikely on Saturday), would be able to get the latest changes and run their test case, as soon as possible, before the end of this day (say, 10pm PST). As much as I'd like to release this in 1.1 so containers using this optimization can use Struts-EL effectively, I will not commit this today unless I get a good response before this evening. -- =================================================================== David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
