What changes when JAX-RS runs in GlassFish instead of Tomcat/Jetty?
What is Grizzly and why does it often appear with Jersey?
What does standalone runtime mean?
Who owns startup, shutdown, thread pools, ports, and configuration?
What should be verified before assuming runtime behavior?

1. Servlet container deployment
   Example mental model: Tomcat/Jetty + Jersey ServletContainer

2. Full Jakarta EE application server
   Example mental model: GlassFish/Payara-like server with Jakarta EE services

3. Embedded HTTP runtime
   Example mental model: Java main starts Grizzly/Jetty/Tomcat programmatically

4. Standalone framework runtime
   Example mental model: executable JAR owns server lifecycle behind framework abstraction

Who starts the HTTP listener?
Who registers resources/providers?
Who owns dependency injection?
Who owns transactions?
Who owns configuration?
Who owns graceful shutdown?
Who owns metrics/access logs?

org.glassfish.jersey.*

import org.glassfish.jersey.server.ResourceConfig;
import org.glassfish.jersey.servlet.ServletContainer;

Tomcat
Jetty
GlassFish
Grizzly embedded
custom standalone runtime

I saw org.glassfish.jersey, therefore runtime is GlassFish.

I saw Jersey. Runtime still needs to be verified from bootstrap/deployment artifact/logs.

[ ] Apakah ada GlassFish server image/runtime?
[ ] Apakah ada Grizzly bootstrap class?
[ ] Apakah ada Tomcat/Jetty dependency?
[ ] Apakah startup log menyebut actual server connector?
[ ] Apakah Dockerfile menjalankan server atau executable app?

domain/server instance
deployment unit
web container
EJB/CDI/JTA/JMS/JPA services if enabled/used
resource adapters
datasource managed by server
security realm/config
admin config

GlassFish starts
  -> initializes server services
  -> deploys application artifact
  -> initializes web/JAX-RS/CDI components
  -> exposes endpoints
  -> manages server resources

some resources may be configured outside application code
some services may be container-managed
startup failure may come from server config, not app code
deployment descriptor may matter
classloading can be server-controlled

Tomcat/Jetty style:
  Mostly web container + application-provided libraries.

GlassFish style:
  Jakarta EE application server + container-provided services.

CDI may be integrated by server
JTA may be available
JPA datasource may be server-managed
security realm may exist
JAX-RS may be part of server runtime
classloading may differ from embedded/executable app
admin config may affect app behavior

Available in server does not mean used by application.
Used by application must be proven from code/config/deployment.

[ ] Apakah artifact dideploy ke full application server?
[ ] Apakah datasource dikelola server atau app/pool library?
[ ] Apakah transaksi memakai JTA atau manual/local transaction?
[ ] Apakah CDI dikelola server?
[ ] Apakah security realm/server auth dipakai?
[ ] Apakah ada deployment descriptor khusus server?

Java main
  -> create ResourceConfig
  -> create Grizzly HTTP server using ResourceConfig
  -> start server on host/port
  -> Jersey handles JAX-RS lifecycle

public final class Main {
  public static void main(String[] args) throws Exception {
    ResourceConfig config = new ResourceConfig()
        .packages("com.company.quoteorder.api");

    HttpServer server = GrizzlyHttpServerFactory.createHttpServer(
        URI.create("http://0.0.0.0:8080/api/"),
        config
    );

    Runtime.getRuntime().addShutdownHook(new Thread(server::shutdownNow));
    Thread.currentThread().join();
  }
}

there may be no web.xml
there may be no Servlet filter chain
server mapping is defined in bootstrap URI/config
application owns server lifecycle
JAX-RS ResourceConfig is central
thread pool and network settings may be configured programmatically

Client
  -> Grizzly HTTP server
  -> Jersey runtime
  -> JAX-RS request matching
  -> resource method

Client
  -> Servlet container connector
  -> Servlet filter chain
  -> Jersey ServletContainer
  -> JAX-RS request matching
  -> resource method

Servlet-specific APIs may not be available or may behave differently.
Servlet filters may not exist.
web.xml may not exist.
context path/mapping model differs.
bootstrap is usually code-driven.
container-level config may live in Java config rather than server config.

Does this change assume Servlet APIs are available?

main method
server startup
port binding
resource registration
config loading
dependency wiring
thread pool setup
shutdown hook
dependency cleanup
readiness lifecycle

Pros:
  explicit startup path
  easier containerization
  single artifact owns its runtime
  less server magic
  easier local execution

Cons:
  app must implement lifecycle carefully
  more responsibility for shutdown and resource cleanup
  thread/connector tuning may be missed
  observability/access log may need explicit setup
  runtime conventions may vary per service

1. process starts
2. config is loaded
3. logging initialized
4. DI/container initialized
5. ResourceConfig/Application created
6. resources/providers/features registered
7. DB/Kafka/Redis/HTTP clients initialized or lazily prepared
8. HTTP server created
9. port bound
10. readiness exposed

server port opens before dependencies are ready
readiness returns OK before resources are initialized
lazy startup hides missing binding until first production request
expensive initialization blocks without timeout
startup failure logs are unstructured

fail fast for required config
validate required dependency wiring
separate liveness from readiness
bind server only after critical bootstrap succeeds, or keep readiness false
log startup phases clearly
expose build/version/runtime metadata safely

[ ] Di mana config dimuat?
[ ] Kapan ResourceConfig dibuat?
[ ] Kapan dependency penting diinisialisasi?
[ ] Kapan server mulai listen?
[ ] Kapan readiness true?
[ ] Apakah startup failure terlihat jelas di logs?

stop accepting new requests
drain in-flight requests
stop background consumers/workers
flush logs/metrics/traces
close DB pools
close HTTP clients
close Kafka producers/consumers
release file handles
exit within Kubernetes termination grace period

Runtime.getRuntime().addShutdownHook(new Thread(() -> {
  server.shutdownNow();
}));

readiness false
server graceful shutdown
workers stop polling
in-flight work drains with deadline
resources close in dependency order
force exit only after deadline

[ ] Apakah SIGTERM ditangani?
[ ] Apakah server punya graceful shutdown?
[ ] Apakah Kafka/worker/background jobs berhenti rapi?
[ ] Apakah DB pool ditutup?
[ ] Apakah shutdown order terdokumentasi?
[ ] Apakah termination grace period cukup?

HTTP acceptor / selector threads
worker threads
application executor
scheduled executor
DB connection pool
Kafka consumer threads
HTTP client connection pool threads
background job threads

HTTP worker blocked by DB/downstream call
small thread pool causing low concurrency
unbounded executor causing memory pressure
scheduled task blocks shared executor
shutdown hook waits forever

which executor runs request code
which executor runs background code
which calls are blocking
which queues are bounded
which timeout protects each wait

[ ] Di mana thread pool HTTP dikonfigurasi?
[ ] Apakah ada custom executor?
[ ] Apakah queue bounded?
[ ] Apakah blocking work dipisah?
[ ] Apakah metrics thread pool tersedia?

host = 0.0.0.0
port = 8080
basePath = /api
baseUri = http://0.0.0.0:8080/api/

binds to localhost inside container, not reachable from outside
port mismatch with Kubernetes Service targetPort
base URI includes /api but ingress also adds /api
base URI missing trailing slash causing route issues
hardcoded port conflicts with platform standard

[ ] Process listens on expected host/port?
[ ] Container exposes correct port?
[ ] Kubernetes Service targetPort matches container port?
[ ] Readiness probe path includes correct base path?
[ ] Ingress path rewrite matches runtime base path?

system properties
environment variables
property files
YAML files
Kubernetes ConfigMap/Secret
cloud config store
command-line arguments
internal config service

What is precedence order?
Are required configs validated?
Are secrets separated from ordinary config?
Are defaults safe?
Can config reload at runtime?
Is config snapshot logged safely?

local default accidentally used in production
secret logged during startup
wrong profile selected
config drift across pods
runtime reload changes behavior unexpectedly

[ ] Di mana config loader berada?
[ ] Apa precedence order?
[ ] Bagaimana profile/environment dipilih?
[ ] Apakah missing config fail fast?
[ ] Apakah secret redacted?

ResourceConfig config = new ResourceConfig()
    .register(QuoteResource.class)
    .register(GlobalExceptionMapper.class)
    .register(CorrelationFilter.class)
    .packages("com.company.quoteorder.api");

explicit class registration
package scanning
feature registration
binder registration
provider auto-discovery

explicit registration is clear but verbose
package scanning is convenient but can hide accidental inclusion/exclusion
auto-discovery reduces boilerplate but makes runtime behavior less obvious

resource not registered
provider registered twice
wrong package scanned
test runtime differs from production runtime
auto-discovered provider changes behavior after dependency upgrade

[ ] Apakah resource registration explicit atau scanning?
[ ] Apakah test memakai ResourceConfig yang sama?
[ ] Apakah provider registration deterministic?
[ ] Apakah auto-discovery aktif?
[ ] Apakah startup log mencetak registered resources/providers?

server classloader
application classloader
shared libraries
provided dependencies

application classpath owns most libraries
fat jar/shaded jar may relocate classes
container image includes runtime dependencies

works locally but fails in server due to provided dependency mismatch
NoSuchMethodError due to version conflict
ClassNotFoundException for provider
duplicate provider because dependency brought multiple modules
JAXB/Jackson provider mismatch

Do not only check source code. Check dependency tree and runtime packaging.

[ ] Apakah dependency Servlet/Jakarta/Jersey scope `provided` atau bundled?
[ ] Apakah ada dependency conflict Jakarta vs javax?
[ ] Apakah shaded/fat jar digunakan?
[ ] Apakah server menyediakan library yang juga dibundled app?
[ ] Apakah dependency tree diverifikasi di CI?

access log or equivalent request log
application structured log
correlation ID
request latency metric
HTTP status metric
in-flight request metric
thread pool metric
error metric
startup/shutdown events

no access log, cannot confirm request reached process
all 404s look like application errors
thread pool saturation invisible
startup failures unstructured
shutdown kills request without trace

[ ] Apakah standalone runtime punya access log?
[ ] Apakah request log punya method/path/status/latency?
[ ] Apakah correlation ID masuk access log?
[ ] Apakah thread pool metrics tersedia?
[ ] Apakah startup/shutdown event tercatat?

liveness  = process should be restarted if false
readiness = process should receive traffic if true
startup   = process is still starting and should not be killed too early

liveness checks DB and causes restart storm
readiness returns true before server/dependencies ready
health endpoint goes through same auth filter as public API
health endpoint depends on slow downstream call
readiness does not turn false during shutdown

liveness: minimal internal process health
readiness: dependency/config/runtime readiness with bounded timeout
startup: large initialization window if needed

[ ] Apa path liveness/readiness/startup?
[ ] Apakah health endpoint JAX-RS resource atau container/platform endpoint?
[ ] Apakah readiness menguji dependency penting?
[ ] Apakah check punya timeout?
[ ] Apakah readiness false saat shutdown?

ResourceConfig-only test
  -> tests JAX-RS resources/providers without real network

Embedded HTTP test
  -> starts Grizzly/Jetty/Tomcat on random port
  -> sends real HTTP request

Container integration test
  -> starts service artifact in Docker/Testcontainers
  -> tests packaging/runtime/config behavior

path mapping
provider registration
serialization
filter ordering
ExceptionMapper
real client behavior

Dockerfile
JVM flags
port binding
config/secret mounting
Kubernetes-style env vars
startup/shutdown behavior

[ ] Apakah test memakai ResourceConfig production?
[ ] Apakah embedded test memakai random port?
[ ] Apakah container image diuji sebelum deploy?
[ ] Apakah health endpoint diuji?
[ ] Apakah startup failure path diuji?

wrong base URI
wrong package scanning
resource class not registered
provider registration fails at startup
classloader/dependency issue

server binds wrong port
readiness path missing base path
binds to localhost instead of 0.0.0.0
startup time exceeds probe threshold
health endpoint protected by auth filter

different ResourceConfig
different config profile
different classpath
container image missing resource file
gateway path rewrite not represented in test

server kills in-flight request
client retries unknown outcome
Kafka producer not flushed
DB transaction committed but response lost
outbox publisher interrupted mid-batch

provider auto-discovery changed
dependency conflict resolved differently
JSON provider changed priority
default thread pool changed
security defaults changed

1. Runtime identity
   What server/runtime is actually running?

2. Artifact type
   WAR, JAR, fat JAR, container image, external server deployment?

3. Startup path
   Who creates server, ResourceConfig, DI container, dependencies?

4. Port/base path
   What host/port/base URI is bound?

5. Resource registration
   Are resources/providers registered as expected?

6. Request path
   Does external path match runtime base path and @Path?

7. Thread/timeout/resource limits
   Are threads, pools, and timeouts sufficient?

8. Health/readiness
   Does platform route only when ready?

9. Shutdown
   Are in-flight requests and background workers drained?

[ ] Does the change alter startup order?
[ ] Does it alter ResourceConfig/Application registration?
[ ] Does it assume Servlet APIs in a non-Servlet runtime?
[ ] Does it change base URI, port, context path, or routing prefix?
[ ] Does it introduce lazy initialization that may fail on first request?
[ ] Does it add a background worker without shutdown handling?
[ ] Does it change thread pool, queue, timeout, or connector settings?
[ ] Does it expose health/readiness correctly?
[ ] Does it preserve access logging and correlation?
[ ] Does it affect local/test runtime differently from production runtime?
[ ] Does dependency scope match actual deployment model?

Runtime
[ ] Does the service run in GlassFish, Grizzly, Tomcat, Jetty, or another runtime?
[ ] Does `org.glassfish.jersey` only indicate Jersey library, or actual GlassFish server?
[ ] Is runtime external or embedded?

Artifact
[ ] Is the deployment artifact WAR, executable JAR, or container image?
[ ] Is there a `main()` launcher?
[ ] Is there server bootstrap code?

JAX-RS registration
[ ] Is `Application` or `ResourceConfig` used?
[ ] Are resources registered explicitly or by package scan?
[ ] Are providers/features/binders registered deterministically?

Lifecycle
[ ] What happens at startup?
[ ] What happens at shutdown?
[ ] Are readiness/liveness/startup probes aligned with runtime lifecycle?

Threading
[ ] Where are HTTP worker threads configured?
[ ] Are background workers separate?
[ ] Are executors bounded and instrumented?

Operations
[ ] Are access logs available?
[ ] Are runtime metrics available?
[ ] Are startup/shutdown events logged?
[ ] Are runtime limits documented?

Dependencies
[ ] Are Jakarta/Jersey/Servlet dependencies bundled or provided?
[ ] Are there javax/jakarta conflicts?
[ ] Is dependency tree stable across local/test/prod?

@Path class + service method + repository

process lifecycle
  + runtime bootstrap
  + HTTP server/container
  + resource registration
  + dependency wiring
  + thread pools
  + config/secret loading
  + health/readiness
  + shutdown behavior
  + observability
  + JAX-RS resource methods

`org.glassfish.jersey` means Jersey library, not necessarily GlassFish server.
GlassFish is a Jakarta EE application server with more container-managed services.
Grizzly is often used as an embedded HTTP runtime for Jersey.
Standalone runtime means the application owns startup, shutdown, config, and server lifecycle.
Servlet APIs should not be assumed available in non-Servlet runtime.
ResourceConfig is often the central artifact in standalone Jersey.
Readiness, shutdown, thread pools, access logs, and dependency scope must be verified.
Runtime identity must be proven from artifact, bootstrap code, deployment config, and logs.