This is an automated email from the ASF dual-hosted git repository.
jungm pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomee-tck.git
The following commit(s) were added to refs/heads/main by this push:
new 5f158b6 enable security 4.0 suite completely
5f158b6 is described below
commit 5f158b642fb3ad896e0e168f6d78b4b327d7d4c5
Author: Markus Jung <[email protected]>
AuthorDate: Sun Aug 23 21:04:01 2026 +0200
enable security 4.0 suite completely
---
KNOWN_ISSUES.md | 22 ++++++----------------
runner-standalone/README.md | 2 +-
runner-standalone/exclusions/security-old.txt | 14 ++------------
3 files changed, 9 insertions(+), 29 deletions(-)
diff --git a/KNOWN_ISSUES.md b/KNOWN_ISSUES.md
index 3beb416..099b87d 100644
--- a/KNOWN_ISSUES.md
+++ b/KNOWN_ISSUES.md
@@ -118,26 +118,16 @@ Fixes belong in Apache TomEE (or Tomcat); each removes
exclusion entries.
runner drives the reactor's modern Arquillian app modules plus the signature
test; the reactor's `old-tck` module (legacy JavaTest suite,
`com.sun.ts.tests.securityapi`) is run by the separate `security-old`
runner.
-6. **Jakarta Security `SecurityContext.hasAccessToWebResource()`** — the
- programmatic access check returns `false` for a caller that is authorized
- for the resource. The old-tck `securitycontext/callerdata` servlet reports
- the correct caller and role membership, but `hasAccessToWebResource(
- "/protectedServlet", "GET")` answers `false` where the spec requires `true`
- for user `tom` (Manager role) against the `@HttpMethodConstraint("GET")`
- resource; TomEE's `SecurityContext` is not wired to the servlet
- authorization/`Policy` layer for this call. Excluded in
- [security-old.txt](runner-standalone/exclusions/security-old.txt)
-
(`securitycontext/callerdata/Client.java#testSecurityContextHasAccessToWebResource`).
-7. **Persistence integration** — undeploy calls `close()` on an
+6. **Persistence integration** — undeploy calls `close()` on an
already-closed `EntityManagerFactory` (fails the
`entityManagerFactoryCloseExceptions` vehicles), and the Jakarta
Persistence 3.2 CDI qualifier beans (`EntityManagerFactory`/
`EntityManager` etc. from `persistence.xml`) are not registered
(`ServletEMLookupTest`). Affects Plume and webprofile alike.
-8. **Jakarta Tags TLD registration** — the `jakarta.tags.*` URIs of the
+7. **Jakarta Tags TLD registration** — the `jakarta.tags.*` URIs of the
replacement Jakarta Tags 3.0 jar are not exposed to applications; all 50
Tags classes plus the EJB-Lite JSP vehicles fail as collateral.
-9. **Transactions — cross-request `UserTransaction` state leakage across
+8. **Transactions — cross-request `UserTransaction` state leakage across
pooled servlet requests.** A `UserTransaction` a servlet/jsp request leaves
in a non-clean state poisons the next request served on the same pooled
Tomcat exec thread; the victim sees an `IllegalStateException` that is not
@@ -158,14 +148,14 @@ Fixes belong in Apache TomEE (or Tomcat); each removes
exclusion entries.
[transactions.txt](runner-standalone/exclusions/transactions.txt). The
Platform catalog additionally shows CDI `@Transactional` interceptors
failing propagation, rollback-rule, and `TransactionScoped` assertions.
-10. **Enterprise Beans** — timer callbacks expose incomplete/not-retried
+9. **Enterprise Beans** — timer callbacks expose incomplete/not-retried
transactions, `java:comp` is mutable where the spec requires
`OperationNotSupportedException`, and failed CDI/EJB deployments leak
deployment IDs (`DuplicateDeploymentIdException` in later apps).
-11. **webprofile ZIP signature leak** — the combined `jakartaee-api` jar
+10. **webprofile ZIP signature leak** — the combined `jakartaee-api` jar
exposes Jakarta Batch and Messaging packages although `javaee.level=web`
does not declare them; strip them or declare and certify them.
-12. **WebSocket 2.2 extension advertising (Tomcat)** — the server-side
+11. **WebSocket 2.2 extension advertising (Tomcat)** — the server-side
configurator reports the extensions the client requested and negotiated.
TomEE's client-side WebSocket container (Tomcat's `tomcat-websocket`)
always advertises its built-in `permessage-deflate` extension in the
diff --git a/runner-standalone/README.md b/runner-standalone/README.md
index 1d40755..015554f 100644
--- a/runner-standalone/README.md
+++ b/runner-standalone/README.md
@@ -86,7 +86,7 @@ derived from; with the default exclusions applied these
suites run green.
| Validation 3.1 | EFTL zip (installed as
`jakarta.validation:validation-tck-tests:3.1.1`) | `validation` | **Runs: 1,049
tests, 0 failures, no exclusions; the mandatory API signature test runs and
passes** against the `jakarta.validation` packages the Plume distribution
ships. Needs AssertJ 3.7.0 pinned (the published TCK jar is compiled against
its covariant signatures) |
| WebSocket 2.2 | EFTL zip (installed as
`jakarta.tck:websocket-tck-spec-tests:2.2.0`) | `websocket` | **Runs: 737
tests, 0 failures, 3 errors** (2026-07-18) against Tomcat's WebSocket
implementation, driven through the `tomcat-websocket` client container; the
signature test passes. The negative-deployment classes run and pass: an invalid
server endpoint aborts the whole webapp deployment as the spec requires, and
the runner's Arquillian extension (`NegativeDeploymentToleranceObserver`) [...]
| Security 4.0 | Source reactor zip 4.0.1 | `security` (Maven module) |
**Runs: 26 app modules plus the signature test, 132 tests, 5 failures, 2 errors
at baseline; green with the reviewed exclusions (all 27 invoker projects pass,
verified end-to-end 2026-07-18)**. The runner downloads and patches the
reactor, injects a tomee-remote profile (including the
`trustStore.path`/`trustStore.password` properties the OpenID modules' keytool
steps read), and drives every module through the Maven [...]
-| Security 4.0 (legacy old-tck) | Source reactor zip 4.0.1 (old-tck built from
bundled sources) | `security-old` (Maven module) | **Baseline 83 tests, 82
pass, 1 failure (Plume, JDK 21, 2026-07-19); green with the reviewed
exclusion.** The legacy JavaTest half exercises ~65
`com.sun.ts.tests.securityapi` Client classes across the idstore (in-war,
database, LDAP), ham (HTTP authentication mechanism) and securitycontext trees.
It deploys through the TCK's own `tomcat` handler (WAR copy int [...]
+| Security 4.0 (legacy old-tck) | Source reactor zip 4.0.1 (old-tck built from
bundled sources) | `security-old` (Maven module) | **Passes 83/83 (0 failures,
0 errors, no exclusions) (Plume, JDK 21, 2026-08-21).** The legacy JavaTest
half exercises ~65 `com.sun.ts.tests.securityapi` Client classes across the
idstore (in-war, database, LDAP), ham (HTTP authentication mechanism) and
securitycontext trees. It deploys through the TCK's own `tomcat` handler (WAR
copy into `webapps/`) against [...]
| Authentication 3.1 | Source reactor zip 3.1.2 | `authentication` (Maven
module) | **Runs: 10 Web Profile modules plus the signature test; green with
the reviewed exclusions (all 11 invoker projects pass, 0 failures)**. The spi
module registers the TCK's test `AuthConfigProvider` under Tomcat's JASPIC
app-context naming (`Catalina/localhost /spitests_servlet_web`), so
`ServletProfileSPITest` runs against Tomcat's `AuthConfigFactory` and passes 56
of its 57 assertions; the runner patches [...]
| Faces 4.1 | Source reactor zip 4.1.2 | `faces` (Maven module) | **Runs:
modern Arquillian modules (faces22/23/40/41) plus the Chrome/Selenium
`old-tck-selenium` modules (ajax, commandLink, protectedViews) — 298 tests, 0
failures, 0 errors, 17 skipped** on Plume's Mojarra, with
`exclusions/faces.txt` applied. The 10 excluded classes are one TomEE product
gap (faces-config.xml unmarshaller rejecting the nonstandard *https*
`xsi:schemaLocation`, `Spec1760IT`) and Mojarra/TomEE integration [...]
| Faces 4.1 (legacy old-tck) | Source reactor zip 4.1.2 (old-tck built from
bundled sources) | `faces-old` (Maven module) | **Passes 5,391/5,391
(standalone mode, no exclusions)** (2026-07-18). The recorded full run shows 5
failures in `htmloutcometargetbutton`, all from a foreign server answering port
8080 mid-run; they pass on re-run against TomEE. The JavaTest half deploys
through the TCK's own `tomcat` handler (WAR copy into `webapps/`) against a
TomEE instance the runner provisions [...]
diff --git a/runner-standalone/exclusions/security-old.txt
b/runner-standalone/exclusions/security-old.txt
index 50bb8a6..7440218 100644
--- a/runner-standalone/exclusions/security-old.txt
+++ b/runner-standalone/exclusions/security-old.txt
@@ -4,15 +4,5 @@
# runner-standalone-security-old module. See KNOWN_ISSUES.md for the
# rationale behind each entry.
#
-# Baseline 2026-07-19 (Plume, JDK 21): 83 tests, 82 passed, 1 failed,
-# 0 errors. The single failure below is a TomEE product gap.
-
-# TomEE product gap: SecurityContext.hasAccessToWebResource() returns false
-# for a caller that is authorized for the resource. The servlet reports the
-# correct caller ("context username: tom") and the authentication path works,
-# but the programmatic access check answers "has GET access ... : false" where
-# the spec requires true for user tom (Manager role) against the
-# @HttpMethodConstraint("GET") /protectedServlet. TomEE's SecurityContext is
-# not wired to the servlet authorization/Policy layer for
-# hasAccessToWebResource(). Assertions Security:JAVADOC:7/8,
Security:SPEC:4.3-1.
-com/sun/ts/tests/securityapi/securitycontext/callerdata/Client.java#testSecurityContextHasAccessToWebResource
+# Baseline 2026-08-21 (Plume, JDK 21): 83 tests, 83 passed, 0 failed,
+# 0 errors. No exclusions: the full suite runs.
