OpenAM 16.0.3 JAXB 1.0 generated classes fail on JDK 21 — JAXBContext initialization returns null

[Bisht-Mohit]

Hi,
We are migrating our sso fedlet library to be compatible with JDK 21 and Tomcat 10.x. As part of this migration, we upgraded from OpenAM 14.x to OpenAM 16.0.3 libraries, which are Jakarta-ized (i.e., they use the jakarta.* namespace instead of the old javax.* namespace).

After deploying the updated WAR on a node running JDK 21, the SSO enable test fails with:

HTTP 500 — SP ID null

The Service Provider entity ID is never populated because SAML metadata parsing fails silently during startup. The root cause is that OpenAM 16.0.3 performed a partial Jakarta migration while the API namespace was updated, the generated SAML implementation classes inside openam-saml2-schema-16.0.3.jar are still JAXB 1.0-style code that depends on com.sun.xml.bind.* classes which have been completely removed from JDK 21.

To Reproduce

1. Build the fedlet WAR with OpenAM 16.0.3 libraries(shaded to Jakarta) and Jakarta JAXB 4.x JARs
2. Deploy the required war/jar on a server running JDK 21 and Tomcat 10.x
3. Proceed to the SSO enablement.
4. SSO enable fails with HTTP 500 — SP ID null

Expected behavior
SSO enable should succeed. The SP entity ID should be populated from the SAML metadata, and the SSO configuration wizard should proceed normally through metadata import, SSO enable, and SSO test.

Environment

• OS: CentOS (Linux-based)
• JDK: 21
• Application Server: Tomcat 10.x
• OpenAM Version: 16.0.3 (Jakarta-ized)
• JAXB Version: Jakarta XML Binding 4.0 (jakarta.xml.bind-api-4.0.2.jar, jaxb-runtime-4.0.5.jar)

Additional context

What we changed Library Upgrades
OpenAM Libraries (14.x → 16.x)

The core OpenAM libraries were upgraded from version 14.0.0-M6 to 16.0.3:

Library	Old Version	New Version
openam-saml2-schema	14.0.0-M6	16.0.3
openam-federation-library	14.0.0-M6	16.0.3
openam-shared	14.0.0-M6	16.0.3
openam-certs	14.0.0-M6	16.0.3
openam-i18n	14.0.0-M6	16.0.3
openam-ldap-utils	14.0.0-M6	16.0.3
openam-idpdiscovery	14.0.0-M6	16.0.3
openam-liberty-schema	14.0.0-M6	16.0.3
openam-wsfederation-schema	14.0.0-M6	16.0.3
openam-xacml3-schema	14.0.0-M6	16.0.3
openam-audit-core	14.0.0-M6	16.0.3
openam-audit-context	14.0.0-M6	16.0.3

Old JARs Removed (incompatible with JDK 21)

Removed JAR	Reason
jaxb-api-1.0.6.jar	Old JAXB 1.0 API — replaced by jakarta.xml.bind-api-4.0.2.jar
jaxb-libs-1.0.6.jar	Old JAXB 1.0 libraries — no longer needed
jaxb1-impl-2.0.2.jar	Old JAXB 1.0 RI — replaced by jaxb-runtime-4.0.5.jar
jaxb-xjc-1.0.6.jar	JAXB code generator — not needed at runtime
xmlsec-1.5.6.jar	Apache Santuario 1.x — replaced by xmlsec-3.0.3.jar
activation-1.1.jar	javax.activation — replaced by Jakarta Activation
javax.servlet-api-3.0.1.jar	javax.servlet — provided by Tomcat 10.x (Jakarta Servlet)
webservices-tools-2.1-b16.jar	Old webservices tooling — not needed
webservices-extra-api-2003-09-04.jar	Old webservices API — not needed
webservices-rt-2009-29-07.jar	Old webservices runtime — not needed
webservices-extra-2008-03-12.jar	Old webservices extras — not needed
webservices-api-2009-14-01.jar	Old webservices API — not needed

New JARs Added

New JAR	Purpose
jakarta.xml.bind-api-4.0.2.jar	Jakarta XML Binding API (replaces old jaxb-api)
jaxb-runtime-4.0.5.jar	JAXB 4.x runtime engine
xmlsec-3.0.3.jar	Apache Santuario 3.x (XML Security — replaces xmlsec-1.5.6)

Root Cause Analysis

OpenAM 16.0.3's Jakarta migration is incomplete:

Layer	What OpenAM 16.x did	Status on JDK 21
API namespace	✅ Migrated javax.xml.bind → jakarta.xml.bind	✅ Works
Runtime engine	✅ Uses JAXB 4.0 runtime	✅ Works
Generated impl classes	❌ Still JAXB 1.0 code structure	❌ Broken
JAXB 1.0 RI internals (com.sun.xml.bind.*)	❌ Not bundled	❌ Missing entirely

The generated classes inside openam-saml2-schema-16.0.3.jar still reference old JAXB 1.0 RI classes:

// Inside OpenAM 16.x generated classes (e.g., EntityDescriptorTypeImpl):
public class EntityDescriptorTypeImpl
    implements com.sun.xml.bind.JAXBObject,                    // JAXB 1.0 RI interface
               com.sun.xml.bind.marshaller.IdentifiableObject  // JAXB 1.0 RI interface
{
    private com.sun.xml.bind.util.ListImpl _Any;               // JAXB 1.0 RI class type
}

These com.sun.xml.bind.* classes were completely removed from JDK 21. Additionally, the JAXB 1.0 and 4.x approaches are fundamentally incompatible:

Aspect	JAXB 1.0 (old approach)	JAXB 4.x (new approach)
How it understands XML structure	Generated GrammarInfo classes describe the schema programmatically	Scans Java classes for annotations like @XmlRootElement, @XmlType
What generated classes look like	implements JAXBObject, uses ListImpl, GrammarInfoImpl	Annotated POJOs with @XmlRootElement, @XmlAccessorType

Since OpenAM's generated classes follow the JAXB 1.0 style (no annotations, implements JAXBObject), the JAXB 4.x runtime cannot understand them. It tries to scan for annotations, finds none, and throws an IllegalAnnotationsException. This causes the JAXBContext to remain null, which means all metadata parsing fails silently, and the SP entity ID is never set.

This triggered a cascade of 5 related issues, each discovered after fixing the previous one.

Question
The core issue is that OpenAM 16.0.3's internal SAML classes are still JAXB 1.0-style generated code, but the JAXB 4.x runtime on JDK 21 only supports annotation-based classes. The old JAXB 1.0 RI classes (com.sun.xml.bind.*) that these generated classes depend on have been completely removed from modern JDKs.

How do we fix this incompatibility so that the existing OpenAM 16.x JAXB 1.0-style generated classes can work on JDK 21 with Jakarta XML Binding 4.x, without modifying the OpenAM libraries themselves?

Thanks in advance,
Mohit.

[maximthomas]

Hi @Bisht-Mohit,

Good question. We have plans to migrate to JAXB 4.x.
If you'd like to contribute and submit a PR, it would be greatly appreciated.

[maximthomas]

Hi @Bisht-Mohit,
1 The OpenAM 16.x Fedlet libraries are not compatible with Jakarta XML Binding 4.x.

2.1 The JAXB 1.0 RI JARs are still bundled.
2.2 There are no integration tests for SAML flows, only unit tests.

3 There is no planned timeline yet for the JAXB 4.x migration.

4.1 You can create a pull request and describe the suggested changes.
4.2 The build specification is defined in the following file: https://github.com/OpenIdentityPlatform/OpenAM/blob/master/.github/workflows/build.yml

[rohithjayak]

Hi @maximthomas,
Thank you for the information. We have a few follow-up questions to clarify the next steps:

1. Just to confirm, is there no workaround to make this compatible with JAXB 3.x? Additionally, are there any OpenAM versions currently bundled with a JAXB version other than 1.0?

2. We reviewed the build.yml file, but it doesn't provide a full picture of the build workflow. Is there a README or documentation that outlines the process for cloning the repo, applying changes, and building the OpenAM JARs with JAXB 4.x? Also, could you specify which exact version of JAXB 4.x we should use and anything specific which has to be taken care of?

Thanks in advance,
Rohith

[maximthomas]

Hi @Bisht-Mohit

1. Unfortunately, there is no workaround. And I don't know about version any OpenAM version with JAXB other than 1.0
2. You can also check the main README.md file: https://github.com/OpenIdentityPlatform/OpenAM?tab=readme-ov-file#how-to-build-openam-from-source

[rohithjayak]

Hi @maximthomas,

I would like to provide an update on our progress with the OpenAM migration to JAXB 4.x:

We have successfully cloned the OpenAM repository, configured the Maven environment, and verified that the project builds correctly.
Following an impact analysis for the JAXB 4.x migration, we have identified two possible paths:

1. Full Migration: Updating all OpenAM modules. This would be a significant undertaking involving over 1,000 files.
2. Targeted Migration: Updating only the 12 specific OpenAM JARs required for our SSO Enablement functionality. This is a much more contained approach.

We are currently proceeding with the second option (Targeted Migration) as it is more efficient.
Please let us know if you have any concerns or suggestions regarding this direction.

Thanks,
Rohith Jayakumar

[maximthomas]

Hi @rohithjayak ,
Thank you for letting us know about the suggested approach. Could you please provide more details about these files you are updating and how you are updating them?
Thanks!

[rohithjayak]

Hi @maximthomas,
Sorry for the late response, as mentioned before we are performing a Targeted Migration(i.e., only the 12 Jars listed in our previous comments) and for this we were analyzing the changes required and got to know that they are very extensive as follows:

Files to be modified in OpenAM:

Category Count What
Modify Java source files 313 Import fixes (javax→jakarta), dead catch removals, cast fixes, logic fixes
Modify non-Java files 13 8 pom.xml files + 5 other config files
New .java shim files ~60+ *Element.java shims, ObjectFactory.java shims, shadow type overrides — all in openam-schema modules
New resource files 2 jaxb.index files for saml2 schema packages
Deleted (XJC-generated) 2311 Old JAXB 1.x *Impl classes and stale generated types — removed because JAXB 4.x generates cleaner output without separate impl classes

By module (Java files to be modified):

openam-schema — 227 files (shims + shadow types)
openam-federation/OpenFM — 66 files
openam-console — 7 files (current work)
openam-entitlements — 6 files
openam-cli, openam-authentication, openam-shared, etc. — remainder

Please let us know your thoughts.

Also, could you please confirm if any CLA is required for this contribution?

Thanks,
Rohith Jayakumar

[maximthomas]

Hi @rohithjayak ,
Seems about right, thank you! We appreciate your efforts.

Also, could you please confirm if any CLA is required for this contribution?

No CLA is required for contributions to this project.
By submitting a pull request (or any other contribution), you agree that it is licensed under the project's CDDL license.

[rohithjayak]

Hi @maximthomas,
Thanks a lot for the confirmation on changes and the CLA part.
We are discussing few things internally to understand the process to raise the PR for this contribution.
Meanwhile, we would like to know some additional details like:
Once the PR is raised by when will we get it reviewed, approved and merged into the OpenAM repo? Basically, a timeline by when we can get the official OpenAM Jars with these changes.
Because we have some deliverables planned for April end which has a dependency on these jars, so your inputs on the timeline would help us plan accordingly.

Thanks,
Rohith Jayakumar

[maximthomas]

Hi @rohithjayak,
Since OpenAM is an open‑source project maintained by the community, we can’t promise fixed timelines for reviewing or merging PRs — it depends on contributor availability at the time.

If you have strict deadlines, you’re welcome to keep working from your own fork and even publish interim builds for your internal use while the PR goes through the review process. We’ll do our best to look at it as soon as we can, but I can’t commit to a particular date.