[
https://issues.apache.org/jira/browse/TOMEE-4651?focusedWorklogId=1031420&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1031420
]
ASF GitHub Bot logged work on TOMEE-4651:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 21/Jul/26 06:09
Start Date: 21/Jul/26 06:09
Worklog Time Spent: 10m
Work Description: 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 |
| -
Issue Time Tracking
-------------------
Worklog Id: (was: 1031420)
Remaining Estimate: 0h
Time Spent: 10m
> TomEE does not register jakarta.tags.* TLD URIs, breaking all Jakarta Tags 3.0
> ------------------------------------------------------------------------------
>
> Key: TOMEE-4651
> URL: https://issues.apache.org/jira/browse/TOMEE-4651
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
> Reporter: Markus Jung
> Assignee: Markus Jung
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Jakarta Tags 3.0 replaces the old JSTL jar. Its TLD files declare URIs under
> the jakarta.tags._ namespace. TomEE and Tomcat do not expose these URIs to
> applications, so any JSP page that declares a taglib with a jakarta.tags._
> URI fails at JSP compile time.
> This breaks all 50 Jakarta Tags 3.0 TCK test classes. It also breaks the
> EJB-Lite JSP vehicles, which use the same tags and fail as a side effect.
> The TCK's own compatibility class hits the same problem. Of its 38 methods,
> only one avoids a jakarta.tags.* URI; the other 37 fail for the same reason.
> h2. Steps to reproduce / TCK reference
> Run the Jakarta Tags 3.0 TCK against TomEE 11. All ~50 test classes fail,
> plus the EJB-Lite JSP vehicle tests, including:
> * {{**/jstl/**/JSTLClientIT.java}}
> These are currently excluded in {{runner-webprofile/exclusions/tags.txt}} in
> the apache/tomee-tck harness repo. Once TomEE registers the jakarta.tags.*
> TLD URIs, remove this exclusion and rerun the suite to confirm the classes
> pass.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
