ggeorgovassilis / fauxjsp Goto Github PK

Given:

1. a tag file with a declared attribute X
2. a JSP which has a variable X in scope (request.getAttribute("X"))
3. JSP uses the tag file and passes a value for attribute X, e.g.

X=123
<prefix:tagfile X="456"/>

Expected result: "tagfile" reads "456" as the value of X
Actual result: "tagfile" reads "123" as the value of X

TestPerformance.testJspRenderer records dropping renderer performance over last month's commits. The test uses a rather simple, nested, JSP with tagsfiles which renders a large tree of nodes. It used to be able to render a few dozen pages/sec, now it's down to 2 pages/sec.

I'm recording some of the findings and why, for now, I won't fix this issue. In short: fixing the findings would require caching, which introduces state, which is an opportunity for bugs. The stated mission of fauxjsp is to be as simple and robust as possible.

Runtime profiling revealed that beanshell accesses the container class loader multiple times for every invocation, being the highest self-time (3x the next highest self-time).

Interpreter instances stored in BeanshellScriptletRendererImpl.cachedInterpreters are assigned variables which are not cleared after invocation creating a memory leak.

Impact: one BeanshellScriptletRendererImpl instance is created per renderer and thrown away with that renderer after the page is rendered, which means that the memory leak is temporary and lasts for the duration of a page rendering but may be an issue with large, temporary objects. Another issue is that the scriptlet context will contain now variables from earlier invocations.

Mitigation: profiling showed that clearing variables with unset(varname) has a considerable performance impact.

Text (e.g. <node>text</node>) and attribute values (e..g <a attribute="value">) are evaluated by EL with every rendering invocation; it is probably faster to determine during parsing which values contain EL and submit only those for evaluation.

This feature deviates from JSP.

• load tagfiles from classpath
• import jsp fragments from classpath
• include jsp fragments from classpath
• write documentation
• release new artefact

Profiling showed that PrintStream initialisation in BeanshellScriptletRendererImpl is expensive (4 seconds self-time)

Exceptions in beanshell are printed as a generic jsp error but their root cause is omitted.

Profiling showed that Intepreter.eval in BeanShellScriptletRenderImpl takes up 7,5 sec of 11 sec self-time.

Beanshell offers a strict interpreter mode which conforms to Java-only syntax.

• Make this a configurable option
• document the option
• alter documentation which states lenience as a drawback

Profiling showed a moderate performance impact of TimeZone.getDefault() in JspRenderImpl.renderNode()

Hi. Do you plan to certify this implementation? I can help you setting up the TCK if you would like.

However, the current specification of JSP (Jakarta Server Pages) did a rename from javax to jakarta. So it would require renaming the namespace from javax to jakarta.

https://www.agilejava.eu/2021/02/05/compatible-implementations/
https://jakarta.ee/specifications/pages/3.0/

the <%@include %> instruction passes garbled "classpath:" paths to the resource resolver

1. introduce a "production mode" flag
2. when (1) is enabled then the FauxJspServlet caches parsers for requested URLs