jungm opened a new pull request, #2844: URL: https://github.com/apache/tomee/pull/2844
## What Registers the seven [Jakarta Tags 3.0](https://jakarta.ee/specifications/tags/3.0/) taglib URIs (`jakarta.tags.core`, `.fmt`, `.sql`, `.xml`, `.functions`, `.permittedTaglibs`, `.scriptfree`) so JSP pages can actually use them. ## Why Jakarta Tags 3.0 renamed the JSTL taglib URIs from the legacy `http://java.sun.com/jsp/jstl/*` form to the short `jakarta.tags.*` form. The taglibs-standard implementation we shade in `deps/taglibs-shade` predates that rename. The shade only rewrites bytecode (`javax.servlet` → `jakarta.servlet`); it does not touch the TLD descriptors, so the shipped TLDs still declare the legacy URIs only. Confirmed by inspecting the jar — none of its 12 TLDs contains a `jakarta.tags.*` URI. The result is that any page containing ```jsp <%@ taglib uri="jakarta.tags.core" prefix="c" %> ``` fails at JSP compile time. This breaks the entire Jakarta Tags 3.0 TCK, and the EJB Lite JSP vehicles as a side effect since their shared harness imports the same URI. ## How `TomEETldScanner` already pre-populates the TLD cache with the container's own taglibs so they don't have to be parsed on every deployment. This adds the Jakarta Tags URIs as additional keys for those same resources, plus widens the `permittedTaglibs` validator so a page guarded by that TLV may use either spelling. Two details worth a reviewer's attention: - The aliases reuse the **very same** `TldResourcePath` instance rather than constructing new ones. `scanPlatform()` tells myfaces and jstl entries apart by reference identity on the resource path's URL, and `TLD_RESOURCE_TAG_LIB` is keyed on it. Both are load-bearing and commented in the code. - The aliasing lives outside the dumped data block, keeping hand-written logic separate from the pasted TLD metadata. It is a no-op when JSTL is absent (`JSTL_URL == null`), degrading to normal scanning rather than failing. I also corrected the class-level comment. It claimed the file is "generated so we don't really care", which is misleading: there is no generator in the build. The data was dumped once by the `sysout()` method kept commented out at the bottom of the same file and pasted in, and the file has been hand-edited several times since. That `sysout()` is itself stale — it still recognises JSTL entries by the `taglibs-standard-jstlel` jar name whereas the shipped jar is `taglibs-shade-*.jar` — so it can no longer reproduce the file. The new comment says so. ### Considered and rejected Switching to a Jakarta-native implementation (`org.glassfish.web:jakarta.servlet.jsp.jstl:3.0.1`) would be the more principled fix — it ships both namespaces, keeps the same `org.apache.taglibs.standard.*` packages, and self-shades Xalan. Apache Taglibs itself never released a Jakarta version (1.2.5 is still latest), which is why the shade exists at all. But the swap touches ~40 sites across BOMs, assembly descriptors, `jarsToSkip` patterns and jar-name filters, so it does not belong in a bug fix. Probably worth its own issue. ## Testing Unit tests in `TomEETldScannerJakartaTagsTest` cover the alias mapping, legacy URIs still resolving, the validator widening, idempotency, and the no-JSTL no-op. Note these drive the aliasing against a synthetic resource map via reflection, because the shaded taglibs jar is not on that module's test classpath. The real proof is the TCK. Built the plume distro, confirmed the fix is in the shipped `tomee-catalina` jar, and ran the Jakarta EE 11 Web Profile TCK `tags` partition from [apache/tomee-tck](https://github.com/apache/tomee-tck) with the exclusion lifted: | | Before | After | | --- | --- | --- | | Tags suite | all 50 classes fail JSP compilation | **541 tests, 482 passing**, 0 taglib resolution errors | | JSTL 1.0 compatibility class | 37 of 38 methods fail | **33 of 38 pass** | | Tags partition, non-TLD gaps excluded | — | **381 tests, 0 failures, 0 errors** | | EJB Lite JSP vehicles | HTTP 500 before EJB assertions run | **9 of 9 `ClientEjblitejspTest` green** | The shipped jar's `c.tld` still declares only `<uri>http://java.sun.com/jsp/jstl/core</uri>`, so the fact that `jakarta.tags.core` pages now compile can only come from this change. The 8 classes still failing are unrelated to TLD registration: the five `sql/*` classes and the compatibility class hit `SQLSyntaxErrorException: Table/View 'JSTL_TAB1' does not exist` (the harness never creates those Derby tables), and `xmlcore.parse` / `xtransform.transform` fail resolving an external systemId. A matching tomee-tck change narrows `exclusions/tags.txt` to just those. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
