Skip to content

Render every current JSP and Jakarta tag/EL binding through isolated JSP engines #120

Closed

Description

@jmanico

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

  1. changed the title [-]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[/+] on Sep 26, 2026
  2. added
    priority: P2Planned maintenance; follow the ordered batch and documented dependencies.
    area: compatibilityJSP/Jakarta/ESAPI consumers, OSGi and integration fixtures.
    triage: depends-onFollow the explicit predecessor/coverage/tooling dependencies in the issue.
    on Sep 26, 2026
  3. tirupatilakshmidevi6-hub commented on Sep 26, 2026

    @tirupatilakshmidevi6-hub
    Contributor

    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:

    • render the packaged TLDs through real JSP engines;
    • enumerate the TLD bindings so new bindings are automatically covered;
    • verify both tag and EL-function output against focused contract cases;
    • cover null/missing values, Unicode, EL coercion and long input;
    • verify invalid tag bodies and missing required attributes are rejected;
    • run the javax and Jakarta engines in isolated child JVMs;
    • remain compatible with the existing Java 8 CI coverage.

    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?

  4. jmanico commented on Sep 26, 2026

    @jmanico
    MemberAuthor

    This is already done and merged into main, care to review it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: compatibilityJSP/Jakarta/ESAPI consumers, OSGi and integration fixtures.enhancementpriority: P2Planned maintenance; follow the ordered batch and documented dependencies.triage: depends-onFollow the explicit predecessor/coverage/tooling dependencies in the issue.

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions