Wildfly 27 Preference of JDK Xerces over its module Xerces

[Pablo Lozano]

Is there an explanation of why the JDK Xerces implementation is preferred versus the Wildfly Xerces?
This assumption is being made given the apparent path being taken by Wildfly to stop using the Xerces module and instead prefer the JDK one. Also based on comments from this conversation: https://groups.google.com/g/wildfly/c/ux3qRh2-7-k

My understanding is that the Xerces version inside the JDK was quite buggy.

For example:
In Widlfy 26 war applications use by default the Xerces version of the Wildfly Modules and executing the following works:

DatatypeFactory.newInstance().newXMLGregorianCalendar("24:00:00Z");
Returns "24:00"

But on Wildfly 27 which war applications by default use JDK Xerces the same call returns bad results and returns: "00:00"

I tried the above using Temurin OpenJDK both JDK 11 and 17 with same results.

There are many other examples like the above where the JDK Xerces has weird issues.

[Paul Ferraro]

From what I can tell, prior to WF27, the WF xerces module added to the deployment classpath via the web services subsystem.

This appears to have been dropped as part of https://issues.redhat.com/browse/WFLY-16167

See: https://github.com/wildfly/wildfly/commit/ad5614cd09af4bd948a3519943fb31ccc7ee5c57

To ensure that your application uses WildFly's xerces module, simply specify a dependency on the "org.apache.xerces" module.

For details, see: https://docs.wildfly.org/27/Developer_Guide.html#dependencies-manifest-entries

[Pablo Lozano]

Thanks for the answer.
My question is mostly around what is preferred by the Wildfly team:

That application developers use the Jboss Xerces module or that we rely on Xerces provided by the JDKs?

Thanks,
Pablo

[Brian Stansberry]

Our general strategy has been to work to move away from our org.apache.xerces and to rely on the JDK, with an ultimate goal of dropping the org.apache.xerces module. The Apache Xerces fork we provide in the org.apache.xerces module gets minimal maintenance. If you find a bug in JDK Xerces you can file a bug with OpenJDK and hopefully it would be addressed. 

That said, if our Xerces module works better for your application, you can certainly use it.

Thank you for your input here; it's useful to know that people find the JDK Xerces to be problematic.

Best regards,

Brian

[Lumír Návrat]

Just notice. Probably OpenJDK Xerces follow up ISO standard updates about times and 24:00 value.

If this wiki page is correct: https://en.wikipedia.org/wiki/ISO_8601

As of ISO 8601-1:2019/Amd 1:2022, midnight may be referred to as "00:00:00", corresponding to the instant at the beginning of a calendar day; or "24:00:00", corresponding to the instant at the end of a calendar day.^[1] ISO 8601-1:2019 as originally published removed "24:00" as a representation for the end of day although it was permitted in earlier versions of the standard.

Dne sobota 1. dubna 2023 v 0:52:09 UTC+2 uživatel Brian Stansberry napsal: