https://bz.apache.org/bugzilla/show_bug.cgi?id=68596
--- Comment #8 from Mark Thomas <ma...@apache.org> --- I've been looking at this some more. The relevant methods on ELResolver are: getValue() getType() setValue() isReadOnly() convertToType() invoke() At the start of each of those methods, ELContext.isPropertyResolved() should be false. There are, essentially, two approaches to this. 1. Call ELContext.setPropertyResolved(false) before calling any of the relevant ELResolver methods. 2. Call ELContext.setPropertyResolved(false) at the start of each of the relevant ELResolver methods. Currently, Tomcat calls ELContext.setPropertyResolved(false) only at the start of the relevant methods for the CompositeELResolver. The caller is expected to call ELContext.setPropertyResolved(false) for all other uses. While this works for the majority of cases, I suspect - but haven't confirmed - that there are edge cases where the EL processing can be made to fail. Particularly when using an individual resolver rather than the CompositeELResolver. The current approach will resolve in additional calls to ELContext.setPropertyResolved(false) when there are nested CompositeELResolver instances. Fully adopting approach 2 will result in significantly more calls to ELContext.setPropertyResolved(false) as they would need to be added to each ELResolver implementation. Switching to approach 1 may slightly reduce the calls to ELContext.setPropertyResolved(false). Either approach should address any yet to be identified edge case bugs. Some initial work locally on switching to approach 1 found that it was very easy to introduce regressions. Overall optimisation options are limited as there are multiple entry points, the same entry points are also used internally and the code needs to behave correctly in all cases. In summary, I suspect what we have at the moment isn't perfect but it works. While approach 1 is simple to implement and unlikely to trigger regressions it will also make performance a lot worse. Hence I don't think that is worth pursuing. Approach 1 may provide some marginal performance benefit but it comes with a high risk of regressions. My current thinking regarding a way forward is to leave this as an enhancement request. In slower time add some unit tests to improve code coverage and try and tease out some of the potential regressions with a view - over time - to moving towards approach 1. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
