@Path("/quotes")
public class QuoteResource {
    @GET
    @Path("/{id}")
    public QuoteResponse getQuote(@PathParam("id") String id) {
        // handle request
    }
}

- siapa membuat instance resource?
- apakah satu instance dipakai semua request?
- apakah instance baru dibuat per request?
- kapan injection terjadi?
- apakah provider/filter/mapper singleton?
- apakah state di field aman?
- kapan resource mahal dibuat dan ditutup?
- apa yang terjadi saat shutdown/rolling deployment?

same class + different lifecycle = different correctness properties

public class QuoteResource {
    private QuoteCommand lastCommand;
}

Never place mutable request state in a field unless you can prove lifecycle and thread-safety.

Resource method runs once per matched request.
Provider/filter/mapper may be reused across many requests.

request 1 -> QuoteResource instance A
request 2 -> QuoteResource instance B

request 1 -> QuoteResource instance A
request 2 -> QuoteResource instance A
request 3 -> QuoteResource instance A

@Path("/quotes")
public class QuoteResource {
    private final QuoteService quoteService;

    @Inject
    public QuoteResource(QuoteService quoteService) {
        this.quoteService = quoteService;
    }
}

@Path("/quotes")
public class QuoteResource {
    private QuoteCommand currentCommand;
    private String currentTenantId;
}

- lifecycle may change
- async continuation may expose race
- tests may instantiate singleton
- future refactor may register instance manually

Keep request data in local variables, method arguments, immutable command objects, or verified request-scoped context.

- MessageBodyReader
- MessageBodyWriter
- ContainerRequestFilter
- ContainerResponseFilter
- ReaderInterceptor
- WriterInterceptor
- ExceptionMapper

Provider instances may be reused concurrently.

- immutable configuration
- thread-safe dependencies
- stateless helpers

public class AuditFilter implements ContainerRequestFilter {
    private String currentUser;

    @Override
    public void filter(ContainerRequestContext ctx) {
        currentUser = ctx.getHeaderString("X-User");
    }
}

public class AuditFilter implements ContainerRequestFilter {
    private final AuditLogger auditLogger;

    @Override
    public void filter(ContainerRequestContext ctx) {
        String user = ctx.getHeaderString("X-User");
        auditLogger.logRequest(user, ctx.getUriInfo().getPath());
    }
}

public class DomainExceptionMapper implements ExceptionMapper<DomainException> {
    @Override
    public Response toResponse(DomainException ex) {
        return Response.status(422)
            .entity(ErrorResponse.from(ex))
            .build();
    }
}

- choose status code
- build error payload
- attach correlation ID if available
- log at correct level if mapper owns logging decision
- avoid leaking internal details

- perform DB lookup
- call external service
- mutate domain state
- store last exception in field
- implement business recovery

- authentication
- authorization
- correlation ID
- tenant resolution
- logging
- metrics/tracing
- CORS
- request normalization

- shared mutable state
- incorrect ordering
- context not cleared
- request body consumed too early
- response modified after commit
- missing async propagation

correlation filter -> auth filter -> tenant filter -> request logging filter

- compression/decompression
- encryption/decryption
- payload logging with limits
- signature verification
- stream wrapping

Interceptors can accidentally buffer huge payloads.

Read entire request body into memory for logging.

- log size-limited preview
- log checksum/content length
- log metadata instead of full body
- avoid logging PII/secrets

- register resource classes
- register providers
- register filters/interceptors
- register features
- register DI binders
- set properties
- configure packages/scanning

ResourceConfig constructor performs expensive remote calls without timeout.

- build config object
- validate critical settings
- register components
- defer optional dependency health to health checks/readiness

public PricingClient(PricingConfig config) {
    this.client = buildClient(config);
    this.client.callHealthEndpoint(); // remote I/O during construction
}

- validate URI/timeout config in constructor
- check remote availability in readiness or startup validation with explicit timeout/policy

- stop accepting new work
- let in-flight requests finish within grace period
- stop scheduled jobs
- stop Kafka consumers cleanly
- flush producers if required
- close HTTP clients
- close DB pools
- release Redis clients
- stop custom executors
- flush telemetry/logs if supported

Custom ExecutorService created in singleton but never shut down.

public class ExportService implements AutoCloseable {
    private final ExecutorService executor;

    @Override
    public void close() {
        executor.shutdown();
    }
}

Which lifecycle callback is honored by the actual runtime?

Resource is created in random method and no one knows who closes it.

- URI info
- headers
- security context
- request-scoped beans
- request properties
- MDC values

executor.submit(() -> {
    // tries to read request context here
});

TenantId tenantId = requestContext.tenantId();
CorrelationId correlationId = requestContext.correlationId();

executor.submit(() -> {
    process(command, tenantId, correlationId);
});

- logging MDC
- security context
- tenant context
- tracing context
- transaction context

request A sets tenant = T1
thread returns to pool
request B reuses same thread
if not cleared -> request B may see T1

try {
    setContext(ctx);
    proceed();
} finally {
    clearContext();
}

- ExecutorService
- CompletableFuture
- reactive streams
- scheduled jobs
- Kafka consumers
- event listeners
- callbacks

HTTP request scope may not exist.
Servlet request may be completed.
Transaction may be closed.
MDC may be missing.
Security context may not propagate.

Async work must receive explicit immutable context.

public record WorkContext(
    TenantId tenantId,
    UserId initiatedBy,
    CorrelationId correlationId,
    Instant requestedAt
) {}

Open transaction -> call slow external service -> continue transaction

- lock held too long
- connection held too long
- deadlock probability increases
- pool exhaustion
- timeout cascade

- validate input
- load minimal state
- commit local state
- publish outbox/event
- call external system outside DB lock where possible

public QuoteResponse getQuote(String id) {
    Client client = ClientBuilder.newClient();
    return client.target(...).request().get(QuoteResponse.class);
}

Create client once at application startup.
Reuse across requests.
Close at shutdown.

- Is the client documented as thread-safe?
- Where is it created?
- Where is it closed?
- What pool settings exist?

- mapper is fully configured before concurrent use
- modules are registered at startup
- date/time/currency rules are stable
- custom serializers are stateless/thread-safe

- mutating ObjectMapper config at request time
- serializer storing last processed object
- per-tenant serialization config stored in singleton mutable field

- local config snapshot
- polling client
- streaming client
- remote evaluation client

- when does flag data load?
- what is default if provider unavailable?
- does client spawn background threads?
- how is it closed?
- how are stale flags cleaned up?

flag provider unavailable -> all requests fail

@Singleton
public class TenantConfigHolder {
    private TenantConfig currentTenantConfig;
}

public interface TenantConfigProvider {
    TenantConfig get(TenantId tenantId);
}

- resolved per request/message/job
- passed explicitly
- cached safely by tenant key if needed
- never stored as current tenant in singleton mutable field

currentTenant
currentUser
currentRequest
lastRequest
activeQuote

1. correlation filter creates correlation ID
2. auth filter validates token
3. tenant filter resolves tenant
4. authorization filter checks permission
5. logging filter records request outcome

- auth logs lack correlation ID
- tenant cannot be resolved from principal
- authorization runs before authentication
- error response lacks security/audit context

- Which ordering annotation/config is used?
- Are priorities documented?
- Are tests covering order-sensitive behavior?

- missing provider binding
- invalid config
- classloading error
- ambiguous injection
- malformed ResourceConfig

- lazy provider missing
- endpoint not registered
- media type provider missing
- request-scoped object unavailable
- external client not initialized

Critical misconfiguration should fail before traffic.

fail fast for invalid deployment
serve degraded for optional dependency outage

1. pod receives SIGTERM
2. readiness should become false
3. load balancer stops sending new traffic after propagation delay
4. in-flight requests continue until grace period
5. app stops workers/consumers
6. app closes pools/clients
7. process exits

- request terminated mid-flight
- Kafka message processed but offset not committed
- DB transaction aborted unexpectedly
- file stream interrupted
- duplicate processing after restart

- who creates it?
- who injects it?
- is it shared?
- is it thread-safe?
- who stops it?
- what happens if stop fails?

1. Is this object created by JAX-RS, Jersey/HK2, CDI, Servlet, or manually?
2. Is it singleton, request-scoped, per-lookup, or unknown?
3. Is it reused concurrently?
4. Does it have mutable fields?
5. Does it store request/user/tenant state?
6. Does it own external resources?
7. Where are those resources closed?
8. Does it cross async/thread boundary?
9. Does it depend on ThreadLocal/MDC/security context?
10. Does behavior change under load or only after deploy/shutdown?

- ResourceConfig/Application registration
- DI binder/producers
- scope annotations
- provider registration
- logs at startup/shutdown
- thread dump
- heap dump
- connection pool metrics
- Kubernetes pod termination events
- load balancer/gateway logs

[ ] Is the resource/provider lifecycle known?
[ ] Are resource classes stateless or safely scoped?
[ ] Are provider/filter/mapper classes stateless or thread-safe?
[ ] Are mutable fields justified and protected?
[ ] Is request/user/tenant state kept out of singleton fields?
[ ] Are expensive resources created once and reused safely?
[ ] Are expensive resources closed during shutdown?
[ ] Are streams/files closed on success and failure?
[ ] Are custom executors shut down?
[ ] Are ThreadLocal/MDC values cleared in finally blocks?
[ ] Is async work given explicit immutable context?
[ ] Are provider/filter ordering requirements explicit?
[ ] Are startup validations clear and bounded by timeout?
[ ] Does graceful shutdown preserve in-flight work semantics?

[ ] Are JAX-RS resources per-request, singleton, CDI-scoped, or manually registered?
[ ] Are providers singleton/shared by default in the runtime used?
[ ] How are filters/interceptors ordered?
[ ] Which lifecycle callbacks are honored: `@PostConstruct`, `@PreDestroy`, `AutoCloseable`, Servlet lifecycle, custom bootstrap?
[ ] Where are HTTP clients created and closed?
[ ] Where are DataSource/connection pools created and closed?
[ ] Are Kafka producers/consumers application-managed or framework-managed?
[ ] Are custom executors present?
[ ] Are request contexts ThreadLocal, request-scoped bean, explicit object, or header-only?
[ ] Are tenant/user/correlation contexts cleared reliably?
[ ] How does app respond to SIGTERM in container/Kubernetes?
[ ] Is readiness changed before shutdown?
[ ] Are in-flight requests allowed to complete?
[ ] Are scheduled jobs and consumers stopped before process exit?
[ ] Are lifecycle assumptions documented in engineering handbook/onboarding?

1. Lifecycle determines whether field state is safe.
2. Provider/filter/mapper code must assume concurrent reuse unless proven otherwise.
3. Framework context should not be carried into async work.
4. Expensive clients/pools should have one clear owner and one clear close path.
5. Startup should fail for invalid deployment, not optional transient dependency outage.
6. Graceful shutdown is part of correctness, especially for event/job processing.
7. ThreadLocal must be paired with reliable cleanup.
8. Tenant/user/request state should be explicit value, not ambient global state.
9. Registration style can change lifecycle semantics.
10. Verify lifecycle from runtime evidence, not from framework folklore.

- Who creates it?
- How many instances exist?
- Is it shared across requests?
- Does it have mutable fields?
- Does it own resource that must be closed?
- Does it use ThreadLocal/MDC/security context?
- What happens during shutdown?
- What metrics/logs prove lifecycle behavior?