[
https://issues.apache.org/jira/browse/TOMEE-4651?focusedWorklogId=1032358&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1032358
]
ASF GitHub Bot logged work on TOMEE-4651:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 27/Jul/26 08:13
Start Date: 27/Jul/26 08:13
Worklog Time Spent: 10m
Work Description: rzo1 commented on PR #2844:
URL: https://github.com/apache/tomee/pull/2844#issuecomment-5088905464
Confirmed the premise against the shipped jar:
`taglibs-shade-11.0.0-SNAPSHOT.jar`
declares only the legacy URIs in all 16 TLDs, so `<%@ taglib
uri="jakarta.tags.core" %>`
fails at compile time. Aliasing onto the same `TldResourcePath` instances is
the right
call and is actually load-bearing — `scanPlatform()` discriminates myfaces
vs jstl by
reference identity on `path.getUrl()`.
The ordering claim in the description is backwards, though, and that's the
main thing
I want addressed:
- I decompiled `org.apache.jasper.servlet.TldScanner` from tomcat-jasper
11.0.21.
`scan()` runs `scanPlatform()` first, and `parseTld()` only registers a URI
`if (!uriTldResourcePathMap.containsKey(uri))` — first writer wins.
`scanJspConfig()`
is stricter still: it checks `containsKey(taglibURI)` and, if present,
logs a warning
and skips the mapping entirely.
So a WAR bundling a Jakarta-native JSTL does *not* still win. After this
change,
`jakarta.tags.*` is claimed by the container's shaded taglibs-standard-1.2
TLD for
every deployment. Concretely, an app that works around TOMEE-4651 today by
bundling
`org.glassfish.web:jakarta.servlet.jsp.jstl:3.0.1` in WEB-INF/lib gets its
TLDs
silently ignored (that jar isn't in `default.exclusions`, so it's scanned,
parsed and
discarded), and an explicit `<jsp-config><taglib>` override in web.xml is
ignored with
a warning. That removes the only workaround users currently have.
It's arguably consistent with how the legacy
`http://java.sun.com/jsp/jstl/*` URIs
already behave, so I'm not asking you to change the precedence — but it
needs a note
in the commit message and ideally a test pinning the intended precedence.
Smaller ones:
- The no-op guard tests map emptiness rather than JSTL presence, so it logs
spurious
WARNINGs on a distribution where MyFaces is present but JSTL is not.
- `permittedTaglibs` is split on `"\n"`, but the value is
whitespace-separated per the
TLV contract — split on `\s+`.
- Nothing asserts `aliasJakartaTagsUris()` is actually wired into the static
initialiser; unwiring it would leave the test green.
- Description says seven URIs, the code registers five.
Issue Time Tracking
-------------------
Worklog Id: (was: 1032358)
Time Spent: 20m (was: 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: 20m
> 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)
