Package com.ultikits.ultitools.websocket

@Internal package com.ultikits.ultitools.websocket
UltiPanel WebSocket client internals, and the three stable extension points modules use.

Connection lifecycle, reconnect strategy and inbound message dispatch for the link to UltiPanel. The whole subsystem is driven by the framework: it is created after a successful cloud login and torn down on shutdown. The wire protocol is a private contract between this client and the panel worker, and both sides change together, so these internals are not an extension point.

Stable extension points. Three classes of this package are public, stable API for modules, as their own javadoc and COMPATIBILITY.md state:

  • PanelResponderRegistry: the single-owner registry a module uses to claim a request/response responder for a type the framework does not own (as of 6.3.0, WIRE-16; as of 6.3.1 served by the UltiCloud protocol v2 module.request);
  • SensitiveCommandRegistry (as of 6.3.1): the table of commands whose arguments are redacted from everything sent to UltiCloud, reached through UltiTools#getSensitiveCommandRegistry();
  • CloudPlayerLinks (as of 6.3.1): the player-link API, reached through UltiTools#getCloudPlayerLinks().
The package carries @ApiStatus.Internal for everything else in it. The JetBrains annotations cannot mark one class stable inside an internal package, so an IDE's unstable-API inspection flags these three as well; their javadoc and COMPATIBILITY.md are the contract.

As of 6.3.1 the live dispatch path is the UltiCloud protocol v2 agent connection in com.ultikits.ultitools.utils. UltiPanelWebSocketClient and the protocol v1 inbound-message dispatch table that used to serve it are no longer used; the dispatch table was removed in 6.3.1.

This package previously also held a second, superseded dispatch mechanism — a registry-plus-interface pair with five per-message-type implementations, formerly the sole public class of a now-deleted handlers sub-package (WIRE-17) — replaced by the dispatch table above in Phase 1 (plan 01-05) but left in the tree, unreferenced, until it was deleted in 6.3.0 (GEN-11, see compatibility/records/6.3.0.md). A reader arriving here from an old link to that cluster will not find it; this is why.

Since:
6.2.5