Bug 53897 - Customized EL resolver to improve the performance of EL resolving
Summary: Customized EL resolver to improve the performance of EL resolving
Status: RESOLVED DUPLICATE of bug 53896
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Jasper (show other bugs)
Version: trunk
Hardware: PC All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2012-09-19 06:19 UTC by Sheldon Shao
Modified: 2012-10-27 19:22 UTC (History)
0 users

Comparison test case (7.29 KB, application/octet-stream)
2012-09-19 06:19 UTC, Sheldon Shao
CustomizedELResolver (9.30 KB, patch)
2012-09-19 06:20 UTC, Sheldon Shao
Details | Diff
Extension of ScopedAttributeELResolver (710 bytes, patch)
2012-09-19 06:21 UTC, Sheldon Shao
Details | Diff
Patch for how to apply this CustomizdELResolver (2.09 KB, patch)
2012-09-19 06:22 UTC, Sheldon Shao
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sheldon Shao 2012-09-19 06:19:56 UTC
Created attachment 29393 [details]
Comparison test case

CustomizedELResolver is to simplify and make it efficient for EL resolving.

1. The code in CustomizedELResolver is copied from CompositeELResolver.
 2. Performance tuning is focus on getValue, because it was the big hotspot of one page hit if the page includes many ELs.
 3. getValue switchs by "base"
 If the base is null, it follows next steps to check value,
 A. ImplicitObjectELResolverImpl(Optimized from ImplicitObjectELResolverImpl)
 B. Extended ELResolvers
 C. ScopedAttributeELResolverImpl(Extends ScopedAttributeELResolverImpl, supports get value by property name)

 Else the base is not null, it checks extended ELResolvers first, then tries to get value from Map, ResourceBundle, List, Array or Bean one by one until the property was resolved.

Q: Why split extSize == 1 to another block ?
 A: To avoid an additional "context.setPropertyResolved(false);"

Q: Why check value from Map, ResourceBundle, List and Array directly in CustomizedELResolver ?
 A To avoid extra valiation in ELResolver.getValue.

Description for attached files.
 1. CustomizedELResolver: The implementation for this fix.
 2 JspApplicationContextImpl.diff : Patch for how to apply this new resolver.
 3. ScopedAttributeELResolverImpl.java: Extension of ScopedAttributeELResolverImpl.
 4. TestPageContext.java: Test case to compare the new ELResolver with CompositeELResolver
 5. ImplicitObjectELResolverImpl.java: related with another bugzilla https://issues.apache.org/bugzilla/show_bug.cgi?id=53895
Comment 1 Sheldon Shao 2012-09-19 06:20:36 UTC
Created attachment 29394 [details]
Comment 2 Sheldon Shao 2012-09-19 06:21:54 UTC
Created attachment 29395 [details]
Extension of ScopedAttributeELResolver
Comment 3 Sheldon Shao 2012-09-19 06:22:29 UTC
Created attachment 29396 [details]
Patch for how to apply this CustomizdELResolver
Comment 4 Sheldon Shao 2012-09-19 08:00:40 UTC
Related with https://issues.apache.org/bugzilla/show_bug.cgi?id=53896
Comment 5 Jarek Gawor 2012-09-19 14:37:48 UTC
This is essentially a duplicate of https://issues.apache.org/bugzilla/show_bug.cgi?id=53896. From my reading of the JSP 2.2 spec (section 2.9), it implies that the ELResolver used by JSP application should be an CompositeELResolver (which the JasperELResolver.java in 53896 is).
Comment 6 Mark Thomas 2012-10-27 19:22:38 UTC
Yep, the resolver needs to be an instance of CompositeELResolver. The patch in the duplicate is also easier to read. I intend to progress the duplicate rather than this one.

*** This bug has been marked as a duplicate of bug 53896 ***