Repository navigation
Render every current JSP and Jakarta tag/EL binding through isolated JSP engines #120
Description
Reviewed 2026-09-25 (America/Los_Angeles) against main at bd249f5. Execution order and cross-issue ownership: #169. Batch 03.
This scope replaces the dated implementation prescriptions in the original report and earlier comments; linked historical evidence remains useful but must be rechecked before implementation.
Remaining coverage gap
#167 now validates TLD declarations, reflection, invocation and source parity; it does not execute a JSP compiler. #151 added JSON and #168 proposes XML 1.1, so the old fixed 60-binding count is obsolete. Keep this as parser/container integration coverage rather than duplicating reflection tests.
- Use isolated test-only Jasper/container fixtures compatible with each adapter's published API baseline. Select maintained versions and review advisories at implementation time; do not put a conflicting newer JSP API on existing unit-test classpaths.
- Generate/verify coverage from the actual packaged basic and advanced TLDs, including JSON and XML 1.1 once merged, and fail if any supported binding is untested.
- Render hostile text, null/missing values and EL coercions; compare exact emitted bytes to the intended facade contract and test rejection of tag bodies/missing required attributes. Avoid treating the facade oracle alone as evidence that a browser context is safe.
- Cover both Jakarta and legacy javax adapters with the correct engines, or record a specific remaining legacy gap before closing; keep dependencies test-only and libraries at their existing Java/provided API baselines.
- Run the Docker-free checks under normal verify without changing shipped artifacts. Preserve Add isolated packaged-consumer compatibility CI across Java 8–25 #162 and Guard facade mappings and JSP/Jakarta parity #167's existing checks.
Sequence after #131/#168 to avoid rebasing the surface twice. #93 owns whether/how the separate browser app is retained; it must not be retired merely because these byte-comparison tests pass.
Activity
[-]Add an embedded Jasper rendering test for every jakarta tag and EL function[/-][+]Render every current JSP and Jakarta tag/EL binding through isolated JSP engines[/+]tirupatilakshmidevi6-hub commentedon Sep 26, 2026
Hi, I'd like to work on #120.
I reviewed the current JSP/Jakarta tag and EL surfaces and the existing tests. My proposed approach is to add Docker-free integration tests using isolated JSP engines so the javax and Jakarta API classpaths cannot conflict.
The harness would:
I understand #120 is sequenced after #131/#168. I can build the test harness independently and then incorporate the final XML 1.1 bindings once #168 lands.
Before I start implementation, could you confirm that this architecture and sequencing fit the intended scope of #120?
jmanico commentedon Sep 26, 2026
This is already done and merged into main, care to review it?