Servlet container: Tomcat / Jetty / equivalent
Full Jakarta EE server: GlassFish / Payara-like / equivalent
Embedded HTTP runtime: Grizzly / Jetty / Tomcat embedded / equivalent
Standalone service launcher: executable JAR with custom bootstrap

Ada org.glassfish.jersey.*  -> pasti GlassFish server
Ada jakarta.ws.rs.*         -> pasti Jakarta EE full server
Ada ServletContainer        -> pasti Tomcat
Ada Dockerfile              -> pasti standalone JAR
Ada Kubernetes              -> pasti runtime sama di semua environment

Source code
  ↓
Build dependency
  ↓
Bootstrap / entrypoint
  ↓
Packaging artifact
  ↓
Container image
  ↓
Deployment manifest
  ↓
Platform routing
  ↓
Runtime logs
  ↓
Observability signals
  ↓
Operational behavior

- direct runtime dependency
- transitive dependency
- test dependency
- compile-only dependency
- annotation/API dependency
- legacy unused dependency
- dependency inherited dari parent POM
- dependency dibawa oleh internal platform library

@Path("/quotes")
public class QuoteResource {
    @GET
    public Response listQuotes() {
        return Response.ok().build();
    }
}

- apakah implementasinya Jersey, RESTEasy, CXF, atau lainnya
- apakah berjalan di Tomcat, Jetty, GlassFish, Grizzly, atau embedded server lain
- apakah DI dikelola HK2, CDI, Spring, atau custom factory
- apakah deployment artifact WAR atau executable JAR
- apakah request masuk lewat ingress, service mesh, API gateway, atau load balancer langsung

I do not know yet. Here is the evidence I need to verify it.

1. HTTP listener owner
2. Request dispatch owner
3. JAX-RS implementation
4. Resource/provider registration mechanism
5. Dependency injection owner
6. Configuration owner
7. Thread pool owner
8. Transaction owner
9. Shutdown owner
10. Deployment artifact shape
11. Platform routing path
12. Observability instrumentation point

Question:
Can I create a new ExecutorService inside a resource class?

Depends on:
- Who owns lifecycle?
- Is there managed executor?
- Is request context propagated?
- Is graceful shutdown handled?
- Is tracing/MDC propagated?
- Is thread count bounded by container policy?

Question:
Can I rely on @RequestScoped?

Depends on:
- Is CDI active?
- Is HK2 active?
- Which scope annotation is used?
- Is resource instantiated per request or singleton?
- Is request executed synchronously or asynchronously?

src/main/java
src/main/resources
src/test/java
pom.xml
Dockerfile
helm/
k8s/
deploy/
charts/
config/
scripts/

Is this a single service repository?
Is this a multi-module Maven repository?
Is this a shared platform library?
Is this an application service or library consumed by another runtime?
Is there more than one deployable artifact?

root/pom.xml
  service-api/
  service-impl/
  service-web/
  service-db/
  service-contract/
  service-test/

- public Java interface
- DTO contract
- OpenAPI contract
- JAX-RS resource interface
- generated client
- internal shared module

grep -R "jakarta.ws.rs" -n src/main/java
grep -R "javax.ws.rs" -n src/main/java
grep -R "org.glassfish.jersey" -n .
grep -R "ResourceConfig" -n .
grep -R "ServletContainer" -n .
grep -R "ApplicationPath" -n .
grep -R "extends Application" -n src/main/java
grep -R "extends ResourceConfig" -n src/main/java

## Runtime verification notes

- JAX-RS API imports:
- Jersey-specific imports:
- Application subclass:
- ResourceConfig subclass:
- web.xml / initializer:
- main class:
- deployment artifact:
- container image entrypoint:
- runtime observed from logs:

mvn -q dependency:tree
mvn -q dependency:tree -Dincludes=jakarta.ws.rs
mvn -q dependency:tree -Dincludes=javax.ws.rs
mvn -q dependency:tree -Dincludes=org.glassfish.jersey
mvn -q dependency:tree -Dincludes=org.glassfish.hk2
mvn -q dependency:tree -Dincludes=org.glassfish.grizzly
mvn -q dependency:tree -Dincludes=org.apache.tomcat
mvn -q dependency:tree -Dincludes=org.eclipse.jetty
mvn -q dependency:tree -Dincludes=jakarta.enterprise

mvn -pl <module-name> -am dependency:tree

<scope>provided</scope>
<scope>runtime</scope>
<scope>test</scope>

Wrong:
org.glassfish.jersey means GlassFish server.

Better:
org.glassfish.jersey means Jersey libraries are present. Runtime still needs verification.

Wrong:
jakarta.enterprise.cdi-api means CDI works.

Better:
CDI API alone does not create a CDI container. Need implementation/runtime/bootstrap evidence.

Wrong:
servlet-api dependency means app runs in Tomcat.

Better:
Servlet API means Servlet programming model is available. Container must be verified separately.

grep -R "public static void main" -n src/main/java
grep -R "new ResourceConfig" -n src/main/java
grep -R "new ServletContainer" -n src/main/java
grep -R "GrizzlyHttpServerFactory" -n src/main/java
grep -R "ServerFactory" -n src/main/java
grep -R "Tomcat" -n src/main/java
grep -R "Jetty" -n src/main/java
grep -R "ApplicationPath" -n src/main/java
grep -R "WebApplicationInitializer" -n src/main/java

@ApplicationPath("/api")
public class QuoteOrderApplication extends Application {
}

- JAX-RS application class exists
- base application path may be /api

- implementation
- container
- DI model
- deployment artifact

public class QuoteOrderResourceConfig extends ResourceConfig {
    public QuoteOrderResourceConfig() {
        packages("com.example.quoteorder.api");
        register(GlobalExceptionMapper.class);
        register(AuthenticationFilter.class);
    }
}

- Jersey-specific bootstrap class exists
- resources/providers may be registered through Jersey ResourceConfig

- how ResourceConfig is connected to container
- whether all environments use this class
- whether additional providers are auto-discovered
- whether internal platform library mutates registration

<servlet>
  <servlet-name>Jersey Web Application</servlet-name>
  <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
  <init-param>
    <param-name>jakarta.ws.rs.Application</param-name>
    <param-value>com.example.QuoteOrderResourceConfig</param-value>
  </init-param>
</servlet>

<servlet-mapping>
  <servlet-name>Jersey Web Application</servlet-name>
  <url-pattern>/api/*</url-pattern>
</servlet-mapping>

- Jersey ServletContainer is configured
- app likely runs in a Servlet container
- URL mapping likely /api/*

- actual container
- context path
- deployment descriptor overrides
- environment-specific packaging

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

        GrizzlyHttpServerFactory.createHttpServer(
            URI.create("http://0.0.0.0:8080/"),
            config
        );
    }
}

- standalone Java main starts HTTP server
- Grizzly likely owns listener/threading
- app probably packaged as executable JAR

- port source
- shutdown hook
- TLS/proxy boundary
- thread pool config
- readiness/liveness path

ls -lh target/
find target -maxdepth 1 -type f

*.war
*.jar
*-runner.jar
*-all.jar
*-shaded.jar

- deployed into Servlet container or Jakarta EE server
- container owns HTTP listener
- app may not have public static void main
- Servlet mapping matters

- app owns server lifecycle or framework owns it
- main class matters
- Docker CMD likely runs `java -jar`

jar tf target/app.jar | head
jar xf target/app.jar META-INF/MANIFEST.MF
cat META-INF/MANIFEST.MF

Main-Class:
Start-Class:
Class-Path:

- dependency conflicts hidden inside artifact
- duplicate service provider files
- wrong provider auto-discovery
- signature files causing runtime issue

jar tf target/app.jar | grep -E "jersey|hk2|grizzly|tomcat|jetty" | head -50
jar tf target/app.jar | grep "META-INF/services" | head -50

cat Dockerfile
cat docker/Dockerfile
find . -iname '*Dockerfile*' -maxdepth 4

FROM eclipse-temurin:17-jre
COPY target/app.jar /app/app.jar
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

FROM tomcat:10-jre17
COPY target/app.war /usr/local/tomcat/webapps/ROOT.war

FROM payara/server-full
COPY target/app.war $DEPLOY_DIR

- base image
- Java version inside image
- entrypoint
- exposed port
- user/non-root
- JVM options
- environment variables
- mounted config paths
- healthcheck
- timezone
- CA certificates
- truststore/keystore

docker build -t runtime-check .
docker inspect runtime-check
docker run --rm runtime-check java -version
docker run --rm runtime-check env
docker run --rm -p 8080:8080 runtime-check

docker pull <image>
docker inspect <image>

Deployment
StatefulSet
Job
CronJob
Service
Ingress
ConfigMap
Secret
ServiceAccount
HorizontalPodAutoscaler
PodDisruptionBudget

find . -iname '*.yaml' -o -iname '*.yml' | grep -E 'k8s|helm|chart|deploy|manifest'
grep -R "kind: Deployment" -n .
grep -R "containerPort" -n .
grep -R "readinessProbe" -n .
grep -R "livenessProbe" -n .
grep -R "JAVA_TOOL_OPTIONS" -n .

containers:
  - name: quote-order-service
    image: registry.example.com/quote-order-service:1.2.3
    ports:
      - containerPort: 8080
    env:
      - name: JAVA_TOOL_OPTIONS
        value: "-XX:MaxRAMPercentage=70"
    readinessProbe:
      httpGet:
        path: /health/ready
        port: 8080

- container port
- health endpoint path
- JVM flags
- environment variable config
- resource limits
- lifecycle hooks

Ingress path
  -> Service port
  -> Pod containerPort
  -> Runtime listener port
  -> Servlet context path
  -> JAX-RS application path
  -> Resource @Path

Ingress path: /quote-order/api
Servlet mapping: /api/*
Application path: /api
Resource path: /quotes

/quote-order/api/api/quotes

/api/api/quotes

/api/quotes

curl -v https://<host>/<path>
curl -v https://<host>/<path>/health
curl -v -H 'Accept: application/json' https://<host>/<path>

kubectl get ingress
kubectl describe ingress <name>
kubectl get svc
kubectl describe svc <name>
kubectl get pods -l app=<app>
kubectl logs deploy/<deployment> --tail=200
kubectl port-forward deploy/<deployment> 8080:8080
curl -v http://localhost:8080/<local-path>

- server banner
- Java version
- listening port
- context path
- Servlet initialization
- Jersey application initialization
- registered resources/providers
- DI startup
- warnings about provider discovery
- health endpoint startup

Started server on port 8080
Initializing Jersey application
Registering application class com.example.QuoteOrderResourceConfig
Root resource classes found:
  com.example.api.QuoteResource
Registered providers:
  com.example.api.GlobalExceptionMapper
  com.example.api.AuthenticationFilter

http-nio-8080-exec-10        -> Tomcat-like
qtp123456-45                 -> Jetty-like
grizzly-http-server-1        -> Grizzly-like
ForkJoinPool.commonPool      -> async code using common pool
pool-7-thread-3              -> custom executor, unclear owner

jcmd <pid> Thread.print
jstack <pid>

kubectl exec -it <pod> -- jcmd 1 Thread.print

service.name
service.version
deployment.environment
http.route
http.method
http.status_code
server.address
server.port
container.name
k8s.pod.name
k8s.namespace.name
thread.name
exception.type

Do traces show servlet span?
Do traces show JAX-RS resource span?
Is route templated or raw path?
Are 404/405 generated by gateway, container, or JAX-RS?
Are errors mapped by ExceptionMapper or thrown before JAX-RS?

DNS / TLS / gateway / ingress / service / container / servlet / filter / request matching

## Runtime conclusion

Based on:
- artifact: WAR
- Docker base image: tomcat:10-jre17
- web.xml: Jersey ServletContainer mapped to /api/*
- dependency: jersey-container-servlet-core
- startup logs: Apache Tomcat banner and Jersey application initialization

Conclusion:
The service appears to run as a Jersey/JAX-RS application inside a Servlet container runtime, likely Tomcat for this environment.

Open questions:
- whether all environments use the same runtime image
- whether production adds API gateway path rewrite
- whether CDI is active or only HK2 is used
- whether ResourceConfig is mutated by internal platform libraries

Who constructs resource classes?
Who constructs service classes?
Who owns singleton lifecycle?
Who owns request scope?
Who injects config?
Who runs producer/factory methods?

grep -R "AbstractBinder" -n src/main/java
grep -R "Factory<" -n src/main/java
grep -R "org.glassfish.hk2" -n src/main/java pom.xml
grep -R "@Service" -n src/main/java

register(new AbstractBinder() {
    @Override
    protected void configure() {
        bind(QuoteService.class).to(QuoteService.class).in(Singleton.class);
    }
});

find . -name beans.xml -print
grep -R "jakarta.enterprise" -n src/main/java pom.xml
grep -R "@ApplicationScoped" -n src/main/java
grep -R "@RequestScoped" -n src/main/java
grep -R "@Produces" -n src/main/java
grep -R "@Inject" -n src/main/java

grep -R "new .*Service" -n src/main/java
grep -R "static .*INSTANCE" -n src/main/java
grep -R "getInstance()" -n src/main/java

application.properties
YAML files
system properties
JVM flags
environment variables
Kubernetes ConfigMap
Kubernetes Secret
mounted files
cloud config service
internal platform config
feature flag service
command-line arguments

Where is the value read?
When is it read?
Can it change at runtime?
What happens if it is missing?
What happens if it is malformed?
Is it logged?
Is it secret?
Is it tenant-specific?

- health path
- readiness vs liveness semantics
- startup probe if slow startup
- dependency checks
- whether DB/Kafka/downstream checks are included
- whether health endpoint is JAX-RS resource or platform endpoint
- whether it requires auth
- whether it is exposed externally

Liveness checks DB.
DB has transient issue.
Kubernetes restarts all pods.
System enters cascading failure.

liveness  -> is process alive or irrecoverably stuck?
readiness -> should this pod receive traffic?
startup   -> has app completed slow initialization?

When pod receives SIGTERM, who handles it?
Does runtime stop accepting new requests?
Are in-flight requests allowed to complete?
Are Kafka consumers paused/stopped?
Are HTTP clients closed?
Are DB pools closed?
Are custom executors shut down?
Is there preStop hook?
Is terminationGracePeriodSeconds enough?

grep -R "shutdown" -n src/main/java
grep -R "close()" -n src/main/java
grep -R "Runtime.getRuntime().addShutdownHook" -n src/main/java
grep -R "ExecutorService" -n src/main/java
grep -R "KafkaConsumer" -n src/main/java
grep -R "DataSource" -n src/main/java

grep -R "terminationGracePeriodSeconds" -n .
grep -R "preStop" -n .

- injection fails at startup
- request scope object not available
- provider constructed twice
- singleton unexpectedly shared
- config injection missing
- tests pass with one runtime but production differs

1. Check dependency tree.
2. Find Application/ResourceConfig bootstrap.
3. Identify container integration.
4. Check CDI implementation and integration.
5. Check startup logs for CDI initialization.
6. Verify object lifecycle with logs/breakpoints.

Any new scope annotation must be reviewed against actual DI runtime.
Any new provider/resource lifecycle assumption must cite runtime evidence.
Any new custom executor must show context propagation and shutdown behavior.

- local path bypasses ingress rewrite
- context path differs
- servlet mapping differs
- application path duplicated
- service mesh strips prefix
- API gateway requires trailing slash differently
- CORS/preflight blocked before app
- auth gateway rejects before JAX-RS

1. Test through external gateway.
2. Test through ingress host.
3. Test with kubectl port-forward.
4. Test inside pod using localhost.
5. Compare response headers and error body.
6. Check access logs at each layer.

local: embedded runtime
CI: test container runtime
staging: Kubernetes image v1
production: Kubernetes image v2 with platform sidecar
customer on-prem: different base image or reverse proxy

- different timeout behavior
- different compression behavior
- different max header/body size
- different TLS/truststore behavior
- different path rewrite
- different thread pool
- different logging format

[ ] Identify root POM and active deployable module.
[ ] Identify Java version and Jakarta/javax namespace usage.
[ ] Generate dependency tree for JAX-RS, Jersey, HK2, CDI, Servlet, Grizzly, Tomcat, Jetty.
[ ] Distinguish direct, transitive, provided, runtime, and test dependencies.
[ ] Identify parent POM/internal platform dependencies.

[ ] Find Application subclass.
[ ] Find ResourceConfig subclass.
[ ] Find web.xml or servlet initializer.
[ ] Find public static void main.
[ ] Find embedded server factory usage.
[ ] Determine whether runtime is Servlet container, app server, embedded server, or custom standalone.
[ ] Verify runtime in startup logs.

[ ] Determine artifact type: WAR, thin JAR, fat JAR, shaded JAR.
[ ] Inspect manifest and main class.
[ ] Inspect Dockerfile/base image/entrypoint.
[ ] Inspect Kubernetes Deployment/Service/Ingress.
[ ] Verify container port and runtime listener port.
[ ] Verify readiness/liveness/startup probes.

[ ] Map external DNS to gateway/load balancer.
[ ] Map gateway path rewrite.
[ ] Map ingress path.
[ ] Map service port to container port.
[ ] Map servlet/context/application/resource path.
[ ] Verify with curl through gateway and port-forward.

[ ] Identify DI owner: HK2, CDI, both, custom, framework.
[ ] Identify singleton/request scope behavior.
[ ] Identify config injection mechanism.
[ ] Identify resource/provider lifecycle.
[ ] Identify custom executor and shutdown behavior.

[ ] Verify access logs.
[ ] Verify application logs.
[ ] Verify correlation/trace propagation.
[ ] Verify metrics for HTTP server, JVM, DB, Kafka, outbound clients.
[ ] Verify traces show route/resource method where possible.

[ ] Verify graceful shutdown.
[ ] Verify timeout hierarchy.
[ ] Verify max request body/header limits.
[ ] Verify thread pool and connection pool settings.
[ ] Verify health endpoint semantics.
[ ] Verify runtime differences between local/dev/staging/prod/on-prem.

[ ] Does this PR change startup order?
[ ] Does it register new resources/providers/filters/interceptors?
[ ] Does it introduce Jersey-specific APIs?
[ ] Does it introduce CDI/HK2 scope assumptions?
[ ] Does it create custom executors or background threads?
[ ] Does it add config keys? Are defaults safe?
[ ] Does it add secrets? Are they redacted and sourced correctly?
[ ] Does it change Docker image, JVM flags, or entrypoint?
[ ] Does it change Kubernetes port/probe/resource limits?
[ ] Does it change external path or routing assumptions?
[ ] Does it affect graceful shutdown?
[ ] Does it preserve observability and context propagation?

1. Dependency is not runtime proof.
2. Annotation is not lifecycle proof.
3. Local behavior is not production proof.
4. Startup log is stronger than README.
5. Container entrypoint is stronger than naming convention.
6. Kubernetes manifest is stronger than local script.
7. Production trace/log is stronger than assumption.
8. Path bugs are usually composition bugs across layers.
9. DI bugs are usually lifecycle ownership bugs.
10. Shutdown bugs are usually invisible until deploy/incident.

# Runtime Map: <service-name>

## Summary
- JAX-RS implementation:
- Runtime/container:
- Deployment artifact:
- Container image:
- Kubernetes workload:
- External route:

## Evidence
- Dependency tree:
- Bootstrap class:
- ResourceConfig/Application:
- Dockerfile:
- Manifest:
- Startup logs:
- Observability links:

## Request path
Client -> DNS -> Gateway -> Ingress -> Service -> Pod -> Runtime -> JAX-RS -> Resource

## DI model
- HK2:
- CDI:
- Manual construction:
- Scope policy:

## Config model
- Config sources:
- Precedence:
- Secret source:
- Runtime reload:

## Operations
- Health endpoints:
- Timeouts:
- Graceful shutdown:
- Metrics/traces/logs:

## Open questions
- ...

CSG uses GlassFish.
CSG uses Grizzly.
CSG uses Tomcat.
CSG uses HK2 only.
CSG uses CDI.

The codebase appears to use Jersey-specific APIs because ResourceConfig and org.glassfish.jersey packages are present.
The deployment runtime still needs verification from Dockerfile, manifest, startup logs, and internal platform documentation.

- many integrations
- multiple deployment models
- cloud and on-prem variants
- customer-specific configuration
- tenant-specific behavior
- long compatibility windows
- high operational cost of runtime drift

Runtime verification is evidence collection.

JAX-RS API usage does not prove implementation or container.

Jersey dependency does not prove GlassFish server.

Docker/Kubernetes artifacts often reveal more than source code alone.

For senior engineers, runtime knowledge is not trivia. It determines lifecycle, DI, threading, configuration, observability, and production failure modes.