Admin client login fails with NoClassDefFoundError: jakarta/annotation/Priority (not reproduced on stock 4.6.0)

[abrowning22]

Summary

The 4.6.0 Linux installer's client/lib directory ships none of the
Jakarta EE API jars the admin client's Jersey 3 runtime requires at
reflexive-load time, but it ships javax.annotation-api-1.3.2.jar (the
pre-Jakarta EE 9 legacy coordinate). As a result, a freshly installed 4.6.0
engine fails to log in from the Swing/JNLP admin client with a
NoClassDefFoundError: jakarta/annotation/Priority originating inside
Jersey's ComponentBag.modelFor when the client's ClientConfig registers
its model.

This is not launcher-specific and not truststore-specific. It is a packaging
gap in the distribution.

Environment (all verified against official release)

• Product: Open Integration Engine 4.6.0 (v4.6.0 tag, shipped 2026-07-09,
  asset oie_unix_4_6_0-*.sh / oie_unix_4_6_0.tar.gz)
• JDK: Eclipse Temurin 21.0.12 (FX-bundled) — same as the launcher's
  javaHome
• Launcher: sereen.io OIE Launcher 2.2.1 (admin-client launcher; the
  repro is independent of launcher, see "Repro without the
  launcher" below)
• Client: mirth-client.jar + Jersey 3.1.10 runtime
• DB: Derby (default)

What ships in 4.6.0 client/lib (verified on the tag)

Fetched OpenIntegrationEngine/engine/client/lib at ref=v4.6.0 (85 files):

• jakarta.ws.rs-api: ABSENT
• jakarta.inject-api: ABSENT
• jakarta.annotation-api: ABSENT
• jakarta.validation-api: ABSENT
• jakarta.xml.bind-api: ABSENT
• javax.annotation-api: present (1.3.2) — the legacy EE 8 coordinate,
  which does NOT satisfy any jakarta.* import

The client's Jersey 3.1.10 runtime (jersey-core-3.1.10.jar,
jersey-client-3.1.10.jar, jersey-common-3.1.10.jar, hk2-*) links
against the jakarta.* namespaces. A javax.annotation-api jar does not
provide them.

Symptoms (client console, at login)

java.lang.NoClassDefFoundError: jakarta/annotation/Priority
    at org.glassfish.jersey.model.internal.ComponentBag.modelFor(ComponentBag.java:529)
    at org.glassfish.jersey.model.internal.ComponentBag.lambda$registerModel$10(ComponentBag.java:454)
    at org.glassfish.jersey.model.internal.ComponentBag.register(ComponentBag.java:283)
    at org.glassfish.jersey.internal.CommonConfig.register(CommonConfig.java:413)
    at org.glassfish.jersey.client.ClientConfig$State.register(ClientConfig.java:217)
    at org.glassfish.jersey.client.ClientConfig.register(ClientConfig.java:621)
    at com.mirth.connect.client.core.Client.<init>(Client.java:188)
    at com.mirth.connect.client.ui.LoginPanel$8.doInBackground(LoginPanel.java:426)
    ...
Caused by: java.lang.ClassNotFoundException: jakarta.annotation.Priority
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
    ...

Follow-on failures in the same family that surface once Priority is
patched (each is a separate NoClassDefFoundError against a different
jakarta.* API that is also missing from client/lib):

• jakarta.ws.rs.core.Configuration
• jakarta.validation.*
• jakarta.xml.bind.*

Repro (without the launcher — isolates the packaging defect from launcher

behavior)

1. Obtain the official oie_unix_4_6_0.tar.gz, extract, run the engine so
   it serves the webstart JNLP on https://<host>:8443.
2. Confirm the missing jars on the server itself:
   ls /server/client-lib/ | grep -i 'jakarta.'
   Expected on 4.6.0: only javax.annotation-api-1.3.2.jar; none of the
   five jakarta.* API jars are present.
3. Run the admin client directly against the served JNLP:
   jnlp /mirth-client.jnlp
   or via the standard sereen.io OIE Launcher pointing at the same address.
4. Click Log In. The client surfaces the red error; the real stack trace
   shown above is in ~/.launcher/logs/<profile-id>.log (launcher) or the
   client console (direct jnlp).

The NoClassDefFoundError reproduces on every fresh 4.6.0 install on
JDK 21 regardless of truststore state, SNI state, or launcher version,
because the missing jars are simply not in the distribution.

Why it breaks (mechanism)

• jakarta.ws.rs-api-3.1.0 (Jersey 3 JAX-RS API) and its peers expose
  @jakarta.annotation.Priority, jakarta.validation.*, jakarta.xml.bind.*
  as type-level references resolved at runtime by Jersey's
  ComponentBag/ModelBuilder.
• Because client/lib does not ship the API jars, the client JVM's
  AppClassLoader has no provider for the jakarta.* namespaces at all;
  the first reflexive access (inside Client.<init> at
  Client.java:188, from LoginPanel$8.doInBackground) throws
  NoClassDefFoundError.
• The legacy javax.annotation-api-1.3.2.jar jar is a different coordinate
  and does not satisfy any jakarta.* import (this was verified on the
  JAR: it contains javax/annotation/*.class, not jakarta/annotation/*.class).
• The server-side equivalent (server-lib/javax/jakarta.*) is present on
  4.6.0, which is why the server boots; only the client bundle is
  incomplete.

Verification trail (run locally, 2026-09-08)

• Upstream client/lib at ref=v4.6.0 via GitHub API: 85 files; none of
  the five jakarta.* API jars present; javax.annotation-api-1.3.2.jar
  present.
• unzip -l on the vendored client-lib/jakarta.annotation-api-2.1.1.jar
  in a patched install: jakarta/annotation/Priority.class present,
  Java 8 classfile, 350B — proving the jar is a real API jar, not a stub.
• Live patched install (engine 4.6.0 + 5 Jakarta API jars added to
  client-lib + webstart.jnlp enumerated all 171 client-lib jars,
  SHA-256 all verified): client logs in cleanly.
• The failing stack trace above was reproduced on two separate JDK 21
  builds (21.0.12) with donotcache=true and donotcache=false.

Suggested fix

Add the five missing Jakarta EE 9+ API jars to the client distribution
(client/lib/ + the equivalent setup/client-lib/ target), matching the
versions already used elsewhere in the project:

jakarta.annotation-api 2.1.1
jakarta.validation-api 3.0.2
jakarta.xml.bind-api 4.0.1
jakarta.ws.rs-api 3.1.0 (required by Jersey 3.1.10 JAX-RS API)
jakarta.inject-api 2.0.1 (required by HK2 3.0.6)

Optionally, the legacy javax.annotation-api-1.3.2.jar can remain in
client-lib for backward compat of any javax.*-era code, and it is
orthogonal to the failure above.

This is consistent with the server-main dependency set, which already
pulls all five.

Impact

• Blocks the Swing/JNLP admin client from logging in on a stock 4.6.0
  install with a standard JDK 21.
• Affects 100% of fresh installs (not version-specific, not
  launcher-specific).
• Does not affect the Web UI (separate bundle) or the CLI.
• Workaround (not a fix): install the five jars from Maven Central into
  the engine's server/client-lib/ directory before the first login.
  This is a distribution mutation and not a clean user path.

Severity / area tags

Bug, High. Client. Packaging / JNLP. Java Web Start. JAX-RS.
Jakarta EE 9. Regression risk: none (missing content, not a behavior change).

Repro bundle for triage

Attached (to be added to the issue body when submitted):

1. Full ~/.launcher/logs/<profile-id>.log from a repro run.
2. unzip -l output of client-lib/jakarta.annotation-api-2.1.1.jar
   (the patched-in, working jar — demonstrates the expected class layout).
3. The exact client/lib listing at v4.6.0 from the GitHub API.
4. A minimal Class.forName("jakarta.annotation.Priority") probe class
   run against a 4.6.0 client-lib classpath (fails) and the same
   classpath + the five jars (passes). This proves the classloader
   result, not just the -cp string.

[pacmano1]

I can't reproduce this. I built 4.6.0, ran it on JDK 21.0.12, and logged in with my launcher. No jakarta error anywhere.

Which launcher are you actually using? You list "sereen.io OIE Launcher 2.2.1", but Ballista has no 2.2.1 build. Its latest is 2.0.1 from March. That matters here, so please confirm the exact build.

On the engine side the mechanism doesn't work. The admin client runs Jersey 2.22.1, not 3.1.10. The version catalog pins 2.22.1 for every Jersey module and 3.1.10 appears nowhere in the project. Jersey 2 is the javax generation, and Client.java:187, inside the constructor your stack trace names, registers javax.ws.rs.ext.Provider.class. Nothing in the client imports jakarta.*, so those five jars would do nothing.

The javax equivalents are all in client-lib: javax.ws.rs-api-2.0.1, javax.annotation-api-1.3.2, javax.inject-2.4.0-b31, and the matching hk2 2.4.0-b31 jars. server-lib has none of the five jakarta API jars either, so that isn't why the server boots.

What I would look at instead is classpath order. OIE ships patched overlay jars, jersey among them, and the JNLP lists each overlay ahead of its stock counterpart. A launcher that builds the classpath from a directory scan rather than JNLP order can load the stock class first, and the failure then lands inside Jersey's own initialization, which is where your trace starts. Launcher jar caches are usually keyed on the version string and not cleared on upgrade, so a cache populated by an older build keeps the bad order even after you update.

Worth trying: clear the launcher's jar cache, or run with donotcache, and retry.

The issue also says a repro bundle is attached, including the Class.forName probe. I don't see it. Can you post that and the full client classpath from the failing run?

[pacmano1]

Forgot the link. My launcher is https://github.com/diridium-com/launcher, latest release v2.2.1.

It builds the classpath in JNLP-declared order rather than from a directory scan, which is the ordering problem described above. That is what I tested with on JDK 21.

[pacmano1]

One more thing on the environment. Eclipse Temurin does not ship a JavaFX-bundled JDK. Adoptium's API lists the image types for Temurin 21 as debugimage, jdk, jre, sbom, sources, staticlibs, testimage, and requesting an FX image type returns a 404. So "Eclipse Temurin 21.0.12 (FX-bundled)" is not a build that exists.

That matters because the admin client needs JavaFX. I ran this on Zulu 21.0.12 FX, which does bundle it. A plain Temurin would fail for want of JavaFX, and that failure looks nothing like a jakarta.annotation.Priority NoClassDefFoundError.

So please include the actual JDK vendor and build you used.

[pacmano1]

I renamed this. The original title stated an engine defect as fact, "4.6.0 ships no jakarta.* API jars in client/lib", and that hasn't been established. Anyone scanning the issue list reads it as 4.6.0 being broken, which isn't fair to the project while it's unconfirmed.

The new title keeps your symptom and drops the diagnosis. Tagged question since it's waiting on the launcher build and the JDK vendor.

Happy to put it back if the classpath shows I'm wrong.