Mojarra ships its own copies of the XML schemas it validates configuration documents against, under impl/src/main/resources/org/glassfish/mojarra. Three of them do not come from https://jakarta.ee/xml/ns/jakartaee/ because they could not: the corresponding release was not out yet when they were needed.
What is provisional right now
jakartaee_12.xsd, web-facesconfig_5_0.xsd and web-facelettaglibrary_5_0.xsd were added in #5903. All three return 404 from https://jakarta.ee/xml/ns/jakartaee/, so the two Faces schemas were taken from the API and jakartaee_12.xsd was derived from jakartaee_11.xsd, carrying the only delta EE 12 has over EE 11, which is dropping the web services client include and its group reference.
That is the same route jakartaee_11.xsd originally took, being copied and modified from jakartaee_10.xsd before EE 11 was released. It was then never revisited, and by the time #5903 looked at it, it was missing the eighteen Jakarta Concurrency definitions the published schema had gained: context-service, managed-executor, managed-scheduled-executor, managed-thread-factory and their types. 576 lines short of what it claimed to be, for however many releases. It has been replaced by the published file, and jakartaee_12.xsd re-derived from that.
Nothing referred to the missing types from Faces, so no behavior changed, which is exactly why nobody noticed.
What to do
Replace all three with the published files once EE 12 and Faces 5.0 appear under https://jakarta.ee/xml/ns/jakartaee/, and diff rather than assume, since a provisional copy which is close enough to work is precisely the kind that survives unexamined.
Worth considering
The same check is worth running over the whole directory rather than only these three, and worth automating rather than repeating by hand. FacesSchemaTest currently proves every schema a supported classpath may declare resolves and compiles, which is what caught jakartaee_12.xsd missing during #5903, but it cannot know whether the file is the right one. Verifying the shipped copies against the published ones needs the network and therefore does not belong in the unit test run, but it would fit a release check.
For the record, the state of the rest as of #5903: web-facesconfig_4_1.xsd and web-facelettaglibrary_4_1.xsd are byte identical to the published ones, and the 4_0 pair differs only in trailing whitespace and comment indentation, with no declaration, type or element differing.
🤖 Generated with Claude Code (Opus 5)
Mojarra ships its own copies of the XML schemas it validates configuration documents against, under
impl/src/main/resources/org/glassfish/mojarra. Three of them do not come from https://jakarta.ee/xml/ns/jakartaee/ because they could not: the corresponding release was not out yet when they were needed.What is provisional right now
jakartaee_12.xsd,web-facesconfig_5_0.xsdandweb-facelettaglibrary_5_0.xsdwere added in #5903. All three return404fromhttps://jakarta.ee/xml/ns/jakartaee/, so the two Faces schemas were taken from the API andjakartaee_12.xsdwas derived fromjakartaee_11.xsd, carrying the only delta EE 12 has over EE 11, which is dropping the web services client include and its group reference.That is the same route
jakartaee_11.xsdoriginally took, being copied and modified fromjakartaee_10.xsdbefore EE 11 was released. It was then never revisited, and by the time #5903 looked at it, it was missing the eighteen Jakarta Concurrency definitions the published schema had gained:context-service,managed-executor,managed-scheduled-executor,managed-thread-factoryand their types. 576 lines short of what it claimed to be, for however many releases. It has been replaced by the published file, andjakartaee_12.xsdre-derived from that.Nothing referred to the missing types from Faces, so no behavior changed, which is exactly why nobody noticed.
What to do
Replace all three with the published files once EE 12 and Faces 5.0 appear under https://jakarta.ee/xml/ns/jakartaee/, and diff rather than assume, since a provisional copy which is close enough to work is precisely the kind that survives unexamined.
Worth considering
The same check is worth running over the whole directory rather than only these three, and worth automating rather than repeating by hand.
FacesSchemaTestcurrently proves every schema a supported classpath may declare resolves and compiles, which is what caughtjakartaee_12.xsdmissing during #5903, but it cannot know whether the file is the right one. Verifying the shipped copies against the published ones needs the network and therefore does not belong in the unit test run, but it would fit a release check.For the record, the state of the rest as of #5903:
web-facesconfig_4_1.xsdandweb-facelettaglibrary_4_1.xsdare byte identical to the published ones, and the4_0pair differs only in trailing whitespace and comment indentation, with no declaration, type or element differing.🤖 Generated with Claude Code (Opus 5)