4.6.0 ships no jakarta.* API jars in client/lib — JNLP admin client throws NoClassDefFoundError: jakarta.annotation.Priority on login (JDK 21) #436

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$registerModel10ドル(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.LoginPanel8ドル.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 LoginPanel8ドル.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.