/wiki / java3

ejb-container

2026-09-02T00:00:00.000Z

The Problem

Auto-created stub for broken link [[ejb-container]] — needs human content.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation.

How It Works

To be written.

Visual Explanation

digraph ejb-container {
  rankdir=LR
  node [shape=box style=filled fillcolor="#f0f4ff" fontname="Helvetica"]
  A [label="Stub: ejb-container"]
  B [label="To be written"]
  A -> B [label="needs content"]
}

Semantic Network

graph semantic_ejb-container {
  layout=neato
  node [shape=ellipse fontname="Helvetica" fontsize=11 style=filled]
  THIS [label="ejb container" fillcolor="#ffd700" fontsize=13 style="filled,bold"]
  REL1 [label="Related" fillcolor="#f0f0f0"]
  THIS -- REL1 [label="related"]
}

Key Properties

To be written.

Real-World Example

# TODO: add example

Connections

Related: Index — auto stub, needs proper links

Edge Cases & Gotchas

To be written.

Java3 — Map of Content

2026-09-02T00:00:00.000Z

Map of Content for Java3 — 44 concepts. Start here to navigate java3.

Core Concepts

API Gateway Pattern — concept
DispatcherServlet — concept
Distributed Tracing — concept
Hibernate Annotations — concept
Hibernate Caching — concept
Hibernate Entity Mapping — concept
Hibernate ORM Framework — concept
Hibernate Query Language — concept
Java Microservices — concept
JPA Pagination and Sorting — concept
JPA Query Methods — concept
JpaRepository — concept
JUnit Annotations and Lifecycle — concept
JUnit Parameterized Tests — concept
JUnit Testing — concept
monolithic-vs-microservices — concept
Service Discovery and Registry — concept
servlet-vs-jsp — concept
Spring Annotations — concept
Spring AOP Advice Types — concept
Spring AOP — concept
Spring Autowiring — concept
Spring Bean Lifecycle — concept
Spring Boot Actuator — concept
Spring Boot Auto-Configuration — concept
Spring Boot — concept
Spring Boot REST API — concept
Spring Cloud API Gateway — concept
Spring Cloud — concept
Spring Cloud Service Discovery — concept
Spring Controller — concept
Spring Data JPA — concept
Spring Form Handling — concept
Spring Framework — concept
Spring IoC Container — concept
Spring JDBC Template — concept
Spring MVC Exception Handling — concept
Spring MVC — concept
Spring ORM — concept
Spring Security Authentication — concept
Spring Security CSRF and JWT — concept
Spring Security — concept
Spring Expression Language — concept
Test-Driven Development — concept

Mechanisms & How Things Work

Auto-generated — edit to curate. Pages that explain processes/flows.

Comparisons & Tradeoffs

(No synthesis yet — create via ingest or query —save)

api-gateway-pattern

2026-05-13T00:00:00.000Z

The Problem

In a microservices architecture, clients (web, mobile, third-party) would need to know about every service, handle authentication individually, and orchestrate multiple service calls for a single page. This creates tight coupling between clients and backend services, duplicates security logic, and forces clients to manage network complexity.

Core Idea

The API Gateway Pattern introduces a single entry point that routes client requests to the appropriate microservices. The gateway handles cross-cutting concerns — authentication, rate limiting, logging, request transformation — in one place. It can also aggregate responses from multiple services, reducing client-side complexity.

How It Works

Single entry point: All client requests go through the gateway, not directly to services
Route matching: Gateway maps incoming request paths to target services — GET /api/users/* → User Service
Authentication: Gateway validates JWT tokens or API keys before forwarding requests — unauthenticated requests are rejected at the edge
Rate limiting: Gateway tracks request rates per client and throttles excessive requests
Request/response transformation: Gateway can modify headers, rewrite paths, transform request/response bodies
Aggregation: A single client request might trigger multiple downstream calls — gateway aggregates responses
Backend for Frontend (BFF): Different gateways for different client types (web, mobile, IoT), each optimized for its client

Visual Explanation

Key Properties

Single entry point: All external requests go through the gateway — simplifies client code
Authentication at edge: Validate tokens/API keys once at gateway, not per service
Rate limiting: Per-client rate limits prevent abuse and ensure fair usage
Request aggregation: Combine multiple service responses into one client response
Protocol translation: Gateway can translate between protocols (HTTP to gRPC, WebSocket polling)
Backend for Frontend (BFF): Separate gateways optimized for specific client types
Load shedding: Gateway can reject requests under load to protect downstream services

Connections

Built from: Spring Cloud API Gateway — Spring Cloud’s implementation of the API Gateway pattern
Built from: Java Microservices — API Gateway is a fundamental component of microservice architecture
Related: Spring Cloud Service Discovery — Gateway uses service discovery to route to instances
Related: API Gateway Pattern — The general architectural pattern (self-reference)
Contrasts with: EJB Object — EJB Object is a client-side proxy; API Gateway is a server-side entry point

Edge Cases & Gotchas

Gateway SPOF: If the gateway goes down, all requests fail — deploy multiple gateway instances behind a load balancer
Latency addition: Every request passes through the gateway, adding network hops — keep gateway logic lightweight
Gateway bloat: Avoid putting business logic in the gateway — it should only handle cross-cutting concerns
BFF vs single gateway: Single gateway works for simple architectures; BFF scales better with diverse client requirements
WebSocket and gRPC: Gateway must support non-HTTP protocols if services use WebSocket or gRPC

dispatcher-servlet

2026-05-13T00:00:00.000Z

The Problem

Without a central request-handling mechanism, every web page in an application manages its own request processing independently. This leads to duplicated infrastructure code (parameter parsing, security checks, view selection) scattered across pages, making the application hard to maintain and evolve.

Core Idea

DispatcherServlet is Spring MVC’s front controller — a single servlet that receives all HTTP requests and delegates to specialized components for each step of request processing. It acts as the central entry point, coordinating handler mapping, controller execution, exception handling, and view resolution.

How It Works

Request received: All HTTP requests are mapped to DispatcherServlet in web.xml
HandlerMapping lookup: DispatcherServlet asks HandlerMapping to find the controller method matching the URL
HandlerAdapter: Adapter invokes the controller method, adapting to different controller types
Controller executes: Method processes the request, returns ModelAndView (or @ResponseBody)
Exception resolution: HandlerExceptionResolver catches controller exceptions and maps them to error views
View resolution: ViewResolver converts logical view name to actual view implementation
View rendering: View renders the model and sends the HTTP response

Visual Explanation

Key Properties

Front controller: Single entry point for all web requests
Pluggable components: HandlerMapping, HandlerAdapter, ViewResolver, ExceptionResolver all configurable
Default behavior: Spring Boot auto-configures sensible defaults for all components
Servlet API independence: Controllers don’t directly depend on HttpServletRequest/Response
Integration: Works with Spring Security’s filter chain seamlessly

Connections

Built from: Spring MVC — DispatcherServlet is the core of Spring MVC
Built from: Spring Framework — DispatcherServlet is a Spring-managed bean wired via IoC
Related: Spring Controller — Controllers are the handlers that DispatcherServlet invokes
Related: Spring MVC Exception Handling — HandlerExceptionResolver integrates with DispatcherServlet
Contrasts with: EJB Object — EJB Object is a proxy; DispatcherServlet is a front controller

Edge Cases & Gotchas

Multiple DispatcherServlets: Possible but rare — each defines its own application context, can’t share beans
Static resources: DispatcherServlet must be configured to pass through static resources (CSS, JS) — use <mvc:resources> or default servlet handler
404 without mapping: No HandlerMapping match results in 404 — check servlet mapping URL patterns
Application context hierarchy: DispatcherServlet creates its own WebApplicationContext (child of root context); only sees beans in its own context

distributed-tracing

2026-05-13T00:00:00.000Z

The Problem

In a monolithic application, debugging a request is straightforward — one log file, one thread. In microservices, a single user request spans multiple services, each with its own logs, on different machines. When something fails, finding the root cause requires manually correlating log entries across services — a tedious, near-impossible task.

Core Idea

Distributed tracing tracks a single request across multiple services by propagating a unique trace ID through every service call. Each service records spans (units of work) with timing, status, and metadata. A tracing system (Zipkin, Jaeger) collects and visualizes these spans, showing the full request path, timing breakdown, and errors.

How It Works

Trace ID generation: When a request enters the system (at the API Gateway), a unique trace ID is generated
Propagation: The trace ID and span ID are propagated via HTTP headers (X-B3-TraceId, X-B3-SpanId) to downstream services
Span recording: Each service creates spans for the work it does — e.g., controller method, database query, HTTP call
Annotation: Spans include annotations for key events (client send, server receive, error)
Collection: Services send completed spans to a collector (Zipkin server) asynchronously
Visualization: The Zipkin UI shows a waterfall diagram: one row per span, with timing and parent-child relationships

Visual Explanation

Key Properties

Trace ID: Unique identifier for an entire request across all services
Span: A named, timed unit of work within a service (e.g., “SELECT from orders”)
Parent span: Spans form a tree — parent-child relationships show the call hierarchy
Propagation: Trace context passed via HTTP headers (B3 format: X-B3-TraceId, X-B3-SpanId, X-B3-ParentSpanId)
Sampling: Not every request is traced — sampling rate configurable (e.g., trace 10% of requests)
Visualization: Zipkin Jaeger, or Grafana Tempo show trace timelines as waterfall diagrams

Connections

Built from: Java Microservices — Distributed tracing is essential when requests span multiple services
Related: Spring Cloud — Spring Cloud Sleuth (deprecated) / Micrometer Tracing provides auto-configuration
Related: URL to Rendering — Full Flow Analysis — Both trace end-to-end request flows
Contrasts with: JTA and JTS — JTA propagates transaction context; tracing propagates trace context

Edge Cases & Gotchas

Performance overhead: Generating and reporting spans adds overhead — use sampling, especially at high throughput
Async boundaries: Trace context doesn’t propagate automatically across async boundaries — use @Async + trace context propagation
Sensitive data: Spans may inadvertently capture sensitive data (SQL queries, request bodies) — sanitize span tags
Clock skew: Services on different machines have slightly different clocks — Zipkin adjusts using client/server send/receive timestamps
End-to-end setup: Requires all services to participate — one service without tracing breaks the trace chain

hibernate-annotations

2026-05-13T00:00:00.000Z

The Problem

Early Hibernate used XML mapping files (.hbm.xml) to define how Java classes mapped to database tables. These files were verbose, hard to maintain, and separated the mapping definition from the code it described, making refactoring error-prone.

Core Idea

Hibernate annotations allow developers to specify entity mappings directly in Java code using JPA-standard annotations. The most common annotations replace XML configuration with in-code metadata: @Entity, @Table, @Id, @Column, @GeneratedValue.

How It Works

@Entity: Marks a POJO class as a Hibernate entity mapped to a database table
@Table(name): Specifies the database table name (optional; defaults to class name)
@Id: Marks the primary key field
`@GeneratedValue(strategy): Specifies primary key generation: AUTO, IDENTITY, SEQUENCE, TABLE
`@Column(name, nullable, length): Maps a field to a column with optional constraints
@Transient: Marks a field that should NOT be persisted
`@Temporal(TemporalType.DATE): Specifies date/time precision for java.util.Date fields
`@Enumerated(EnumType.STRING): Specifies enum storage as STRING (name) or ORDINAL (index)

Visual Explanation

Key Properties

JPA-standard: Annotations come from javax.persistence.* (or jakarta.persistence.*), not Hibernate-specific
Zero XML: Full mapping can be done with annotations alone — no .hbm.xml files needed
Compile-time checked: Wrong annotation usage is caught at compile time vs XML’s runtime failures
Default conventions: Unspecified mappings default to sensible conventions (table = class name, column = field name)
Hybrid possible: Annotations can override or supplement XML configurations

Connections

Built from: Hibernate ORM Framework — Annotations are the modern way to configure Hibernate
Built from: Object-Relational Mapping — Annotations map Java objects to relational tables
Related: Hibernate Entity Mapping — Relationship annotations (@OneToOne, @OneToMany, @ManyToMany)
Contrasts with: EJB Deployment Descriptor — XML-based vs annotation-based configuration
Builds into: Spring Data JPA — Spring Data JPA entities use the same JPA annotations

Edge Cases & Gotchas

Field vs property access: @Id placement determines access strategy — on field (FIELD access) or getter (PROPERTY access); mixing causes issues
Default column names: Auto-generated column names follow naming strategy; explicit @Column(name) avoids surprises
GenerationType.IDENTITY: Disables batch inserts because the DB must generate the ID before Hibernate knows it
@Enumerated(ORDINAL): Default is ORDINAL (numeric), which breaks if enum ordering changes — prefer STRING

hibernate-caching

2026-05-13T00:00:00.000Z

The Problem

Database access is expensive — each query requires network round trips, SQL parsing, and disk I/O. Applications often read the same data multiple times within a short period. Without caching, every read hits the database, wasting resources and increasing latency.

Core Idea

Hibernate provides a multi-level caching architecture: the first-level cache (mandatory, session-scoped) stores entities loaded within a single session; the second-level cache (optional, session-factory-scoped) is shared across sessions; the query cache caches query results and their entity identifiers.

How It Works

First-level cache: Every Hibernate Session has its own cache. When session.get() loads an entity, Hibernate checks this cache first. If found, no database call. The cache is flushed (written to DB) at transaction commit or explicit session.flush()
Second-level cache: Pluggable cache (Ehcache, Redis, Infinispan) configured on the SessionFactory. When enabled for an entity, Hibernate checks L1 → L2 → database. L2 is shared across all sessions
Query cache: Caches query result identifiers (not entities). Requires second-level cache to be enabled. On re-execution, returns cached IDs and loads entities from L2 cache
Cache concurrency strategies: READ_ONLY (immutable data), READ_WRITE (frequent updates), NONSTRICT_READ_WRITE (rare updates), TRANSACTIONAL (full JTA support)

Visual Explanation

Key Properties

L1 cache: Mandatory, session-scoped, cannot be disabled. Entities are removed when session is closed
L2 cache: Optional, session-factory-scoped. Requires a cache provider (Ehcache, Redis)
Query cache: Optional, caches query result identifiers, requires L2 cache
Cache regions: Named regions allow fine-grained TTL and eviction policies per entity or query
Concurrency: Four strategies (READ_ONLY, READ_WRITE, NONSTRICT_READ_WRITE, TRANSACTIONAL) matching data mutation patterns

Connections

Built from: Hibernate ORM Framework — Caching is a built-in Hibernate feature
Related: Spring ORM — Spring manages Hibernate sessions and transaction boundaries around caching
Contrasts with: Instance Pooling — Pooling caches bean instances; Hibernate caching caches database data
Related: Passivation — Both are memory management strategies (passivation serializes, caching keeps in memory)
Builds into: Spring Data JPA — Spring Data JPA inherits Hibernate’s caching when using Hibernate as JPA provider

Edge Cases & Gotchas

L1 cache scope: L1 cache only lives as long as the Session — in a stateless (stateless session) scenario, there is no L1 cache benefit
L2 cache invalidation: Stale data occurs if another process modifies the database directly; use cache region timeouts
Query cache invalidation: Any insert/update/delete on a cached query’s table invalidates the entire query cache region
Cluster consistency: Distributed L2 caches (Redis) need careful serialization and invalidation strategies
Debugging overhead: Cached results hide database-level changes during development; always clear both caches during testing

hibernate-entity-mapping

2026-05-13T00:00:00.000Z

The Problem

Relational databases model relationships using foreign keys and join tables, while Java models relationships using object references and collections. Translating between these paradigms — one-to-one, one-to-many, many-to-many — requires explicit mapping configuration so Hibernate knows how to persist object graphs.

Core Idea

Hibernate entity mapping defines how Java class relationships correspond to database foreign key and join table structures. The three relationship types mirror SQL: @OneToOne (FK on either side), @OneToMany/@ManyToOne (FK on the many side), and @ManyToMany (join table).

How It Works

One-to-One (@OneToOne): A single entity instance relates to at most one other instance. Implemented via a foreign key column with a unique constraint on one table, or via a shared primary key
One-to-Many (@OneToMany + @ManyToOne): One entity has many children. The child table holds the foreign key. The @ManyToOne side is always the owning side
Many-to-Many (@ManyToMany): Each entity can relate to many of the other. Requires a join table with two foreign key columns. Both sides use @JoinTable with joinColumns and inverseJoinColumns
Unidirectional vs Bidirectional: Unidirectional means only one side navigates to the other; bidirectional means both sides have references

Visual Explanation

Key Properties

Owning side: The side that owns the foreign key; only the owning side’s changes are tracked
mappedBy: Placed on the inverse (non-owning) side to reference the owning side’s field name
Cascade: Propagates operations (PERSIST, MERGE, REMOVE) from parent to child
Fetch type: LAZY (load on access) vs EAGER (load immediately with parent)
Join columns: @JoinColumn specifies the FK column name; @JoinTable specifies the join table for M:N
Inheritance mapping: Single table, joined table, or table-per-class strategies for class hierarchies

Connections

Built from: Hibernate ORM Framework — Mapping is a core feature of Hibernate
Built from: Object-Relational Mapping — Mapping implements ORM principles
Related: Hibernate Annotations — JPA annotations define mappings
Contrasts with: One-to-One Relationship (EJB) — EJB’s CMR vs Hibernate annotations
Builds into: Spring Data JPA — Spring Data JPA repositories operate on mapped entities

Edge Cases & Gotchas

Bidirectional sync: Always add convenience methods like addEmployee(emp) to sync both sides of bidirectional associations
equals/hashCode: Never use the auto-generated ID in hashCode() before persisting — null ID causes inconsistent behavior in collections
EAGER fetch overuse: Loading an entity with multiple EAGER collections creates a Cartesian product query
Join table naming: If @JoinTable name is unspecified, Hibernate generates a default; explicit naming avoids surprises

hibernate-orm-framework

2026-05-13T00:00:00.000Z

The Problem

Writing raw JDBC code for every database operation is repetitive, error-prone, and mixes SQL with Java logic. Object-relational impedance mismatch means Java objects (graphs, inheritance) don’t map naturally to relational tables (flat rows). Developers need a tool that automates this mapping and eliminates boilerplate.

Core Idea

Hibernate is an Object-Relational Mapping (ORM) framework for Java that maps Java classes to database tables and provides automatic SQL generation for CRUD operations. Developers work with Java objects; Hibernate translates those operations into SQL statements transparently.

How It Works

Configuration: A hibernate.cfg.xml file specifies database connection, dialect, and mapping classes
SessionFactory: A thread-safe factory created once per application from the configuration
Session: A lightweight, non-thread-safe wrapper around a JDBC connection, obtained per operation
Transaction: Wraps each unit of work. Hibernate uses its own Transaction API over JDBC transactions
Persistence operations: session.save(obj), session.get(Class, id), session.update(obj), session.delete(obj) — Hibernate generates and executes the SQL
Automatic dirty checking: Hibernate tracks entity state changes and flushes updates to the database automatically

Visual Explanation

Semantic Network

Key Properties

Automatic SQL: Generates INSERT/UPDATE/DELETE/SELECT from object operations
Transparent persistence: Developer works with POJOs, not JDBC
Caching: First-level (session-scoped) and second-level (session-factory-scoped) cache
Lazy loading: Child entities loaded from database only when accessed
HQL: Object-oriented query language using class names instead of table names
Dialects: Database-specific SQL generation (MySQL, Oracle, PostgreSQL, etc.)

Connections

Built from: JDBC — Hibernate uses JDBC under the hood for database connectivity
Built from: Object-Relational Mapping — Hibernate implements ORM principles
Builds into: Spring ORM — Spring integrates Hibernate via SessionFactory and transaction management
Builds into: Spring Data JPA — Spring Data JPA builds on Hibernate as the default JPA provider
Related: Hibernate Query Language — HQL is Hibernate’s object-oriented query language
Contrasts with: Container-Managed Persistence — CMP is EJB’s ORM approach; Hibernate is standalone

Edge Cases & Gotchas

N+1 query problem: Lazy loading a collection in a loop triggers N additional queries; use JOIN FETCH
Open Session in View: Keeping a session open during view rendering can cause LazyInitializationException
equals() and hashCode(): Must implement correctly for entities in collections, but primary keys change before persist
Version field: Optimistic locking requires a @Version annotated field

hql

2026-05-13T00:00:00.000Z

The Problem

Standard SQL uses table and column names, making queries database-specific and tightly coupled to the physical schema. When using ORM, developers want to query using Java class and field names instead, maintaining the object-oriented abstraction even during queries.

Core Idea

HQL (Hibernate Query Language) is an object-oriented query language that operates on entity class names and their fields instead of table and column names. HQL queries are translated by Hibernate into native SQL for the configured database dialect. Hibernate also supports Native SQL queries for database-specific features.

How It Works

HQL syntax: from Employee e where e.department.name = :deptName — uses class and field names
Query creation: session.createQuery("from Employee", Employee.class)
Parameter binding: Named parameters (:paramName) or positional (?1) prevent SQL injection
Translation: Hibernate parses HQL, generates an AST, transforms it to SQL for the target dialect
Result processing: Returns List<Entity> or Stream<Entity> automatically mapped to entities
Native SQL: session.createNativeQuery("SELECT * FROM emp", Employee.class) for raw SQL

Visual Explanation

Key Properties

Object-oriented: Queries use Java class names (Employee) and field names (firstName)
Dialect-independent: Same HQL works on MySQL, Oracle, PostgreSQL — Hibernate handles translation
Named parameters: :name syntax with setParameter("name", value) for safe parameter binding
Aggregation: Supports SELECT, GROUP BY, HAVING, ORDER BY, aggregate functions
Joins: Implicit path navigation (emp.department.name) and explicit JOIN FETCH for loading associations
Native SQL fallback: createNativeQuery() for database-specific features, stored procedures, or complex queries

Connections

Built from: Hibernate ORM Framework — HQL is Hibernate’s query language
Built from: EJB Query Language (EJB-QL) — HQL is the ORM successor to EJB-QL’s concept
Related: JDBC — Native SQL in Hibernate still uses JDBC under the hood
Builds into: Spring Data JPA — Spring Data JPA’s @Query uses JPQL (similar to HQL)
Contrasts with: EJB-QL — EJB-QL is more limited, HQL supports richer expressions and native SQL

Edge Cases & Gotchas

N+1 with joins: Default fetching is LAZY; HQL queries without JOIN FETCH trigger N+1 queries for associations
HQL vs SQL mindset: HQL operates on entities, not rows — select e.firstName, e.lastName returns Object[], not entities
Positional parameters: ? positional params are deprecated in Hibernate 5+ in favor of :named parameters
Scalar queries: Aggregate results need proper typing — query.getSingleResult() returns Long for COUNT, not Integer

java-microservices

2026-05-13T00:00:00.000Z

The Problem

Monolithic applications grow too large to maintain — a single codebase with millions of lines, long build times, brittle deployments where one bug takes down the entire application. Scaling requires scaling the whole app, not just the bottleneck component. Teams can’t work independently on different parts.

Core Idea

Java Microservices is an architectural style where a Java application is structured as a collection of small, independently deployable services, each owning its own database and communicating via lightweight protocols (HTTP/REST or messaging). Each service is developed, deployed, and scaled independently, typically using Spring Boot.

How It Works

Service decomposition: Each business capability becomes a separate service (User Service, Order Service, Payment Service)
Independent deployment: Each service is its own Spring Boot JAR, deployed separately, with its own CI/CD pipeline
Inter-service communication: Services communicate via REST APIs (synchronous) or message queues (asynchronous)
Service discovery: Eureka registry enables services to find each other by logical name
API Gateway: Single entry point routes requests to appropriate services
Database per service: Each service owns its database — no shared database across services
Distributed tracing: Sleuth + Zipkin trace requests across service boundaries for debugging

Visual Explanation

Key Properties

Independent deployability: Each service has its own build, test, deploy pipeline
Decentralized data: Each service owns its database — no shared schema, no cross-service transactions
Technology heterogeneity: Each service can use different technology stacks (though in Java, all typically Spring Boot)
Resilience: Failure in one service doesn’t cascade — circuit breakers, fallbacks, bulkheads
Scalability: Scale only the services that need it (e.g., more Order Service instances during sales)
Team autonomy: Teams own their services end-to-end — development, testing, deployment, operations

Connections

Built from: Spring Boot — Each microservice is a Spring Boot application
Built from: Spring Cloud — Infrastructure (discovery, gateway, config, tracing) comes from Spring Cloud
Built from: Spring Boot REST API — Services communicate via REST APIs
Related: API Gateway Pattern — Gateway is the entry point for all microservice requests
Related: Service Discovery and Registry — Eureka enables service-to-service discovery
Contrasts with: Backend Architecture — Monolithic vs microservices architecture tradeoffs

Edge Cases & Gotchas

Distributed transactions: No ACID across services — use Saga pattern (choreography or orchestration)
Network latency: Inter-service calls add network overhead — use async messaging for non-critical paths
Data consistency: Eventual consistency across services — handle stale data gracefully
Testing complexity: End-to-end testing requires running all services — use contract testing (Pact)
Operational overhead: Monitoring, logging, deploying many services requires mature DevOps practices
Debugging: A single user request spans multiple services — distributed tracing is essential

jpa-pagination-sorting

2026-05-13T00:00:00.000Z

The Problem

Returning all rows from a large database table in a single query consumes excessive memory, slows response times, and overwhelms clients. Without a standard way to page and sort results, developers must manually write LIMIT/OFFSET SQL and handle page navigation, which is tedious and repetitive.

Core Idea

Spring Data JPA provides Pageable (pagination parameters) and Sort (ordering parameters) as standard abstractions for querying subsets of data. Repository methods accept Pageable to return Page<T> objects containing the requested slice plus total count metadata. Sorting can be combined with pagination or used independently.

How It Works

Pageable: Interface with pageNumber (0-indexed), pageSize, and optional Sort
PageRequest: Concrete implementation: PageRequest.of(0, 20, Sort.by("lastName")) — page 1, 20 items, sorted by lastName
Repository acceptance: Page<User> findAll(Pageable pageable) — Spring Data adds LIMIT, OFFSET, and COUNT query
Page response: getContent() (list of entities), getTotalElements(), getTotalPages(), getNumber(), hasNext()
Sort: Sort.by("lastName").descending().and(Sort.by("firstName")) — sort by multiple properties
Slice: Like Page but without total count — more efficient for infinite scroll (no COUNT query)

Visual Explanation

Key Properties

Pageable: Standard parameter for pagination — page number, page size, sort
Page: Full result with content + metadata (total elements, total pages, etc.)
Slice: Lightweight result with just content + navigation info (hasNext, hasPrevious)
Sort: Multi-property sorting with direction (ASC/DESC) and null handling
Default values: @PageableDefault(size=20, sort="id", direction=ASC) for controller parameters
Unpaged: Pageable.unpaged() — return all results without pagination

Connections

Built from: Spring Data JPA — Pagination and sorting are built into Spring Data’s repository abstraction
Built from: JpaRepository — PagingAndSortingRepository provides the findAll(Pageable) method
Related: JPA Query Methods — Derived query methods can accept Pageable: findByLastName(String, Pageable)
Related: Java ArrayList — Page’s getContent() returns a List, typically backed by ArrayList

Edge Cases & Gotchas

OFFSET performance: Large offsets (page=100, size=20 → OFFSET 2000) are slow — use keyset pagination for deep pages
COUNT query cost: COUNT(*) on large tables can be expensive — consider Slice (no COUNT) for infinite scroll
Sort injection: Sort.by("lastName") — property names are validated, not directly interpolated; but still validate user input for sort fields
Sort direction: Default is ASC; specify .descending() for descending
0-indexed pages: page=0 is the first page — this often confuses frontend developers who expect 1-indexed pages

jpa-query-methods

2026-05-13T00:00:00.000Z

The Problem

Every data access operation that isn’t a basic CRUD operation requires writing a query. Defining, testing, and maintaining dozens of custom queries for every entity creates significant boilerplate and couples repository code to the query implementation.

Core Idea

Spring Data JPA’s derived query methods generate database queries automatically from method names. A method like findByLastNameAndAgeGreaterThan(String lastName, int age) is parsed and translated into the corresponding JPQL query at startup, eliminating the need for manual query definitions for standard operations.

How It Works

Method name parsing: Spring Data parses findBy, readBy, countBy, deleteBy as the action prefix
Property references: The parser extracts entity property names from the method name (e.g., LastName, Age)
Criteria keywords: AND, OR, Between, LessThan, GreaterThan, Like, In, IgnoreCase, OrderBy, Null, NotNull
Nested property traversal: findByAddressZipCode(String zip) traverses the Address→zipCode path
Startup validation: At application startup, Spring Data validates that all properties in method names actually exist — errors are caught early
@Query override: If a method name can’t express the logic, @Query("...") provides explicit JPQL

Visual Explanation

Key Properties

Supported prefixes: findBy, readBy, getBy, queryBy, countBy, deleteBy, removeBy
Criteria keywords: And, Or, Between, LessThan, GreaterThan, Like, NotLike, In, NotIn, IgnoreCase, OrderBy, True, False, Null, NotNull, Before, After, StartingWith, EndingWith, Containing
Limiting results: findFirst5By..., findTop10By... — restricts result count
Return types: Entity, Optional<T>, List<T>, Stream<T>, Page<T>, Slice<T>
Validation: Startup validation catches method names that reference non-existent properties

Connections

Built from: Spring Data JPA — Derived query methods are a core feature
Built from: JpaRepository — Derived methods are declared on JpaRepository interfaces
Related: Hibernate Query Language — Both generate JPQL; derived methods are a higher-level abstraction
Contrasts with: EJB Query Language (EJB-QL) — EJB-QL is written in deployment descriptors; Spring Data derives queries from method names

Edge Cases & Gotchas

Method name explosion: findByLastNameAndAgeGreaterThanAndStatusInOrderByLastNameAsc(...) — unreadable; use @Query for complex cases
Distinct: findDistinctBy... for distinct results
IgnoreCase: Works only on String comparisons; added after property: findByLastNameIgnoreCase
Nested property ambiguity: findByAddressZipCode assumes address.zipCode property; if addressZipCode is a direct property, it won’t find it — disambiguate with findByAddress_ZipCode

jpa-repository

2026-05-13T00:00:00.000Z

The Problem

Every data access class needs standard CRUD operations (create, read, update, delete) plus paging and sorting. Writing these methods manually for every entity creates repetitive code that adds no business value and introduces bugs in transaction management, connection handling, and result mapping.

Core Idea

JpaRepository<T, ID> is a Spring Data JPA interface that provides a full set of CRUD, paging, and sorting operations automatically. By extending it, a repository interface inherits findAll(), findById(), save(), delete(), findAll(Pageable), and more — no implementation code required. Spring Data generates the implementation at runtime.

How It Works

Interface hierarchy: Repository (marker) → CrudRepository (basic CRUD) → PagingAndSortingRepository (pagination) → JpaRepository (JPA-specific: flush, batch)
CrudRepository: save(S entity), findById(ID id), findAll(), count(), deleteById(ID id), existsById(ID id)
PagingAndSortingRepository: findAll(Pageable) → returns Page<T> with total count; findAll(Sort) → returns sorted List<T>
JpaRepository additions: findAll() returns List<T> (vs Iterable in CrudRepository), flush(), saveAndFlush(), deleteInBatch(), getById()
Runtime proxy: Spring Data creates a JDK dynamic proxy implementing the interface, using SimpleJpaRepository as the default implementation
Custom methods: Declare findBy... methods; Spring Data parses the method name and generates the query

Visual Explanation

Key Properties

CrudRepository: Base interface with full CRUD — return types are Optional<T> for single result
PagingAndSortingRepository: Adds pagination and sorting support
JpaRepository: Extends both with JPA-specific batch operations and flush control
Query by Example: findAll(Example.of(probe)) — query by example object
Specification: JpaSpecificationExecutor for dynamic criteria queries
@NoRepositoryBean: Marker for intermediate interfaces that shouldn’t be instantiated

Connections

Built from: Spring Data JPA — JpaRepository is the primary repository interface
Built from: Hibernate ORM Framework — SimpleJpaRepository delegates to EntityManager (Hibernate)
Related: JPA Query Methods — Derived query methods extend JpaRepository
Related: JPA Pagination and Sorting — JpaRepository inherits Pageable support
Contrasts with: JDBC — JDBC requires manual SQL; JpaRepository is declarative

Edge Cases & Gotchas

save() semantics: save() is both INSERT and UPDATE — Hibernate checks if ID exists; this can cause extra SELECT queries
getById() vs findById(): getById() returns a reference (proxy, lazy); findById() returns Optional (eager loading)
deleteInBatch vs deleteAll: deleteInBatch() uses one JPQL DELETE query; deleteAll() loads each entity and calls EntityManager.remove()
Transactional behavior: Repository methods are @Transactional(readOnly=true) for reads, @Transactional for writes

junit-annotations-lifecycle

2026-05-13T00:00:00.000Z

The Problem

Tests need setup (creating objects, connecting to databases) and cleanup (closing resources, deleting test data). Without lifecycle methods, every test duplicates setup and cleanup code. Different tests may need different setup, and some tests need to be conditionally included or excluded.

Core Idea

JUnit 5 provides lifecycle annotations that define methods to run before/after all tests and before/after each test. These eliminate duplication and establish a clear fixture lifecycle. @Tag filters which tests run in which environments, and @DisplayName provides readable test descriptions.

How It Works

@BeforeAll: Runs once before any test in the class. Must be static (or use @TestInstance(Lifecycle.PER_CLASS)). Used for expensive setup (DB connection, file system init)
@BeforeEach: Runs before each @Test method. Used to set up test data, create fresh objects, reset state
@AfterEach: Runs after each @Test method (even if the test fails). Used to clean up test data, close resources
@AfterAll: Runs once after all tests. Must be static. Used to close global resources
@Tag: Labels tests for filtering — @Tag("slow"), @Tag("integration"). Maven: mvn test -Dgroups="fast"
@DisplayName: Human-readable test name in reports and IDE — @DisplayName("should return user when valid ID")
@Disabled: Temporarily skip a test (with reason) instead of commenting it out

Visual Explanation

digraph lifecycle_order {
  rankdir=TB
  node [shape=box style=filled fillcolor="#f0f4ff" fontname="Helvetica" fontsize=12]
  edge [fontname="Helvetica" fontsize=10]
 
  CLASS [label="TestClass"]
  B4ALL [label="@BeforeAll\nstatic void init()" fillcolor="#cce5ff"]
  B4_1 [label="@BeforeEach\nvoid setUp()" fillcolor="#cce5ff"]
  TEST1 [label="@Test\ntest1()" fillcolor="#ffe5cc]
  AFT_1 [label="@AfterEach\nvoid tearDown()" fillcolor="#cce5ff"]
  B4_2 [label="@BeforeEach\nvoid setUp()" fillcolor="#cce5ff"]
  TEST2 [label="@Test\ntest2()" fillcolor="#ffe5cc]
  AFT_2 [label="@AfterEach\nvoid tearDown()" fillcolor="#cce5ff"]
  AFTALL [label="@AfterAll\nstatic void cleanup()" fillcolor="#cce5ff"]
 
  CLASS -> B4ALL
  B4ALL -> B4_1
  B4_1 -> TEST1
  TEST1 -> AFT_1
  AFT_1 -> B4_2
  B4_2 -> TEST2
  TEST2 -> AFT_2
  AFT_2 -> AFTALL
}

Key Properties

@BeforeAll: One-time setup, runs once per test class, must be static
@BeforeEach: Setup before every test, fresh state per test
@AfterEach: Cleanup after every test, runs even if test fails
@AfterAll: One-time teardown, runs once per test class
@Tag: Filter tests by category (fast/slow, unit/integration, api/db)
@DisplayName: Human-readable names visible in IDE and HTML reports
@Disabled: Skip test with a descriptive reason; better than commenting out

Connections

Built from: JUnit Testing — Lifecycle annotations are a core part of JUnit 5
Related: JUnit Parameterized Tests — Lifecycle hooks work with parameterized tests too
Related: Try-Catch-Finally — @AfterEach acts like a finally block for each test
Related: Test-Driven Development — TDD relies on well-structured test fixtures

Edge Cases & Gotchas

Static @BeforeAll: Must be static in default PER_METHOD mode; in PER_CLASS mode, can be instance method
@AfterEach runs always: Even if the test throws an exception, @AfterEach runs (like finally) — but if @AfterEach throws, the test may be masked
Tag inheritance: Tags are inherited from parent classes and interfaces
@Disabled vs @Ignore (JUnit 4): JUnit 5 uses @Disabled; JUnit 4 used @Ignore — don’t confuse them
Execution order: Tests should not depend on order, but if needed, use @TestMethodOrder(MethodName/OrderAnnotation/Random)

junit-parameterized-tests

2026-05-13T00:00:00.000Z

The Problem

Testing a method with different inputs requires either writing multiple test methods (one per input) or using loops inside a single test. Multiple tests are repetitive to write and maintain; loops make it hard to identify which input caused a failure.

Core Idea

JUnit 5’s @ParameterizedTest allows running the same test method with different arguments. By providing a source of arguments (@ValueSource, @CsvSource, @MethodSource), the test runs once per argument set, with each run reported independently — making it easy to see exactly which input failed.

How It Works

@ParameterizedTest: Replaces @Test to indicate a parameterized test
@ValueSource: Provides literal values (ints, strings) — @ValueSource(ints = {1, 2, 3})
@CsvSource: Provides comma-separated values for multiple parameters — @CsvSource({"1,2,3", "4,5,9"})
@MethodSource: References a static method that returns a Stream<Arguments> — most flexible
@EnumSource: Provides enum constants as test arguments
@CsvFileSource: Loads test data from a CSV file on classpath
@NullSource / @EmptySource: Provides null and empty values for edge case testing

Visual Explanation

digraph parameterized {
  rankdir=LR
  node [shape=box style=filled fillcolor="#f0f4ff" fontname="Helvetica" fontsize=12]
  edge [fontname="Helvetica" fontsize=10]
 
  TEST [label="@ParameterizedTest\nvoid testAdd(int a, int b, int expected)"]
  SRC [label="Argument Sources"]
  VS [label="@ValueSource\n(single param)"]
  CS [label="@CsvSource\n(multi params)"]
  MS [label="@MethodSource\n(complex args)"]
  ES [label="@EnumSource\n(enum values)"]
  RUN [label="Run 1: (1, 2, 3)\nRun 2: (4, 5, 9)\nRun 3: (0, 0, 0)" fillcolor="#ffe5cc]
  PASS [label="PASS: 1+2=3"]
  FAIL [label="FAIL: 4+5=9?\n(expected 9, got 8)"]
 
  TEST -> SRC
  SRC -> VS
  SRC -> CS
  SRC -> MS
  SRC -> ES
  VS -> RUN
  CS -> RUN
  MS -> RUN
  ES -> RUN
  RUN -> PASS [label="test passes"]
  RUN -> FAIL [label="test fails"]
}

Key Properties

@ParameterizedTest: Replaces @Test for tests that take arguments
@ValueSource: Simple literal values — ints, strings, longs, doubles
@CsvSource: Multiple parameters as CSV — supports null values via empty field
@MethodSource: References a factory method returning Stream<Arguments>, Arguments[], or Stream<T>
@CsvFileSource: Load test data from CSV files (lines = test cases, columns = parameters)
@EnumSource: All enum values or a filtered subset
@NullAndEmptySource: Combines both @NullSource and @EmptySource
Custom display names: @ParameterizedTest(name = "{index}: add({0}, {1}) = {2}")

Connections

Built from: JUnit Testing — Parameterized tests extend JUnit 5’s test capabilities
Related: JUnit Annotations and Lifecycle — Lifecycle hooks work with parameterized tests
Related: SQL Database — @CsvSource provides tabular test data, similar to query result sets
Related: Test-Driven Development — TDD benefits from parameterized tests for boundary value analysis

Edge Cases & Gotchas

MethodSource must be static: Factory methods for @MethodSource must be static (unless PER_CLASS lifecycle)
Type conversion: JUnit automatically converts strings to primitives, but custom types need @ConvertWith or @JavaTimeConversionPattern
Large CSV files: @CsvFileSource for large datasets — but test data in CSV may be harder to maintain than inline
Argument name in display name: Use {0}, {1}, etc. in the name attribute of @ParameterizedTest to reference arguments
Null handling: Primitive parameters can’t accept null — use Integer instead of int for nullable tests

junit-testing

2026-05-13T00:00:00.000Z

The Problem

Software defects are inevitable. Without a systematic testing approach, bugs are found only during manual testing or in production — making them expensive and time-consuming to fix. Developers need a way to automatically verify that code behaves correctly, especially after changes.

Core Idea

JUnit is the standard framework for writing and running tests in Java. JUnit 5 (Jupiter) provides annotations for defining tests (@Test), lifecycle hooks (@BeforeEach, @AfterEach), assertions (assertEquals, assertThrows), assumptions, and test execution control. It integrates with build tools (Maven, Gradle) and CI/CD pipelines.

How It Works

Test class: A plain Java class containing test methods annotated with @Test
Assertions: assertEquals(expected, actual), assertTrue(condition), assertThrows(Exception.class, () → code) — verify results
Lifecycle methods: @BeforeAll (once before all tests, static), @BeforeEach (before each test), @AfterEach (after each test), @AfterAll (once after all tests, static)
Test runner: JUnit discovers test classes (classpath scanning), instantiates a new test instance per method (default behavior), executes lifecycle hooks, runs the test, and reports results
Test suites: @Suite aggregates multiple test classes into a test suite for batch execution
Build integration: Maven Surefire Plugin runs JUnit tests during the test lifecycle phase
Mockito integration: Mockito creates mock objects to isolate the unit under test — @Mock, @InjectMocks, when(mock.method()).thenReturn(value)

Visual Explanation

digraph junit_flow {
  rankdir=TB
  node [shape=box style=filled fillcolor="#f0f4ff" fontname="Helvetica" fontsize=12]
  edge [fontname="Helvetica" fontsize=10]
 
  CLASS [label="Test Class\n(StudentServiceTest)"]
  B4ALL [label="@BeforeAll\n(setup DB connection)"]
  B4 [label="@BeforeEach\n(create test data)"]
  TEST1 [label="@Test\ntestAddStudent()" fillcolor="#ffe5cc]
  TEST2 [label="@Test\ntestDeleteStudent()" fillcolor="#ffe5cc]
  AFT [label="@AfterEach\n(cleanup test data)"]
  AFTALL [label="@AfterAll\n(close DB connection)"]
  ASSERT [label="Assertions\nassertEquals\nassertNotNull\nassertThrows"]
  RESULT [label="Test Result\nPASS / FAIL"]
 
  CLASS -> B4ALL
  B4ALL -> B4
  B4 -> TEST1
  TEST1 -> ASSERT
  ASSERT -> RESULT
  RESULT -> AFT
  AFT -> B4 [label="next test"]
  B4 -> TEST2
  TEST2 -> AFT
  AFT -> AFTALL [label="all done"]
}

Key Properties

@Test: Marks a method as a test; JUnit discovers and executes it
Assertions: Static methods comparing actual vs expected; assertAll() groups multiple assertions
Assumptions: assumeTrue() skips tests when conditions aren’t met (e.g., OS-specific tests)
Lifecycle hooks: @BeforeAll, @BeforeEach, @AfterEach, @AfterAll for setup/cleanup
Parameterized tests: @ParameterizedTest + @ValueSource / @CsvSource — run same test with different inputs
Test templates: @TestTemplate for reusable test skeletons (e.g., repeated tests)
TestInfo/TestReporter: Injection parameters providing test metadata and reporting

Connections

Built from: Try-Catch-Finally — Assertions and lifecycle hooks replace manual try-catch error handling
Related: JUnit Annotations and Lifecycle — The lifecycle annotations and their execution order
Related: JUnit Parameterized Tests — Testing multiple inputs with parameterized tests
Related: Test-Driven Development — TDD uses JUnit as the testing framework
Contrasts with: Java Exception Hierarchy — Exceptions signal runtime problems; JUnit assertions verify correctness

Edge Cases & Gotchas

Test instance lifecycle: Default is PER_METHOD (new instance per test) — @TestInstance(Lifecycle.PER_CLASS) shares instance for stateful tests
assertThrows usage: Must wrap the code in a lambda — assertThrows(IllegalArgumentException.class, () → obj.method())
Test ordering: Tests should be independent — don’t rely on execution order; use @TestMethodOrder if order matters
Mockito annotations: @ExtendWith(MockitoExtension.class) enables @Mock and @InjectMocks
Static methods in tests: @BeforeAll and @AfterAll must be static (unless using PER_CLASS lifecycle)

Monolithic vs Microservices Architecture

2026-05-13T00:00:00.000Z

What’s Being Compared

Monolithic architecture builds an application as a single deployable unit, while microservices architecture decomposes it into independently deployable services. The comparison isn’t about which is “better” — it’s about which set of tradeoffs matches the application’s scale, team structure, and operational maturity.

The Core Tension

Monoliths optimize for simplicity (one codebase, one deploy, one database) at the cost of scalability and team autonomy. Microservices optimize for independence (independent deploy, scale, teams) at the cost of operational complexity (distributed systems, network latency, data consistency).

Comparison

Dimension	Monolithic	Microservices
Deployment	Single WAR/JAR	Multiple service JARs
Scaling	Scale entire app	Scale per service
Team structure	One team per app	One team per service
Testing	Single-process E2E	Contract tests, E2E across services
Database	Single shared DB	Database per service
Inter-service calls	In-process method calls	HTTP/REST or message queue
Data consistency	ACID transactions	Eventual consistency / Saga
Startup time	Slow (big app)	Fast (small service)
Operational needs	Simple (one app to monitor)	Complex (service discovery, tracing)
Fault isolation	One bug takes down everything	Failure isolated to one service

When to Choose Monolithic

Small team (1-10 developers)
Early-stage product (validating market fit)
Simple domain with clear boundaries
Limited DevOps/operations resources
Startup or MVP phase — get to market fast

When to Choose Microservices

Large team (multiple squads)
Proven product at scale
Multiple subdomains with clear boundaries
Mature DevOps practice (CI/CD, monitoring, containers)
Need to scale different parts independently

The Insight

The right architecture depends on team size and organizational maturity, not technology preference. Conway’s Law applies: the architecture mirrors the communication structure. Start with a modular monolith (well-organized single deployable); extract microservices only when the monolith’s constraints outweigh microservices’ complexity. Most successful microservice adoptions started as monoliths.

Connections

Java Microservices — Implementation of microservice architecture in Java
API Gateway Pattern — Entry point for microservice requests
Service Discovery and Registry — Dynamic service location in microservices
Distributed Tracing — Observability across service boundaries
Backend Architecture — General backend architecture patterns including monolith

service-discovery-registry

2026-05-13T00:00:00.000Z

The Problem

In a dynamic microservices environment, service instances start, stop, scale up, and scale down constantly. Clients can’t hard-code IP addresses and ports. Without a discovery mechanism, adding or removing instances requires manual configuration updates, which is error-prone and slow.

Core Idea

Service Discovery and Registry is a pattern where a central registry (Eureka, Consul, ZooKeeper) maintains the network locations of all available service instances. Services register themselves on startup and send heartbeats to stay registered. Clients query the registry to find available instances by logical service name.

How It Works

Registration: Each service instance registers its host, port, health check URL, and metadata with the registry on startup
Heartbeat (renewal): Registered instances periodically send heartbeats (e.g., every 30s) to signal they’re alive
Eviction: The registry evicts instances that miss multiple heartbeats (e.g., 3 missed = 90s)
Discovery: Clients query the registry for a service name → get a list of available instances
Load balancing: Client-side load balancer selects one instance (round-robin, least connections)
Health checks: The registry periodically pings service health endpoints to verify they’re actually healthy

Visual Explanation

Key Properties

Service registry: Central database mapping service names → instance addresses
Self-registration: Services register themselves (vs third-party registration via a separate process)
Heartbeat-based health: Periodic renewal signals liveness; eviction on absence
Client-side discovery: Client queries registry and selects an instance (common in Spring Cloud)
Server-side discovery: Load balancer (Nginx, AWS ALB) queries registry and routes
Caching: Clients cache the registry locally to avoid querying on every request

Connections

Built from: Java Microservices — Service discovery is essential for dynamic microservice environments
Built from: Spring Cloud — Spring Cloud provides Eureka-based service discovery
Related: Spring Cloud Service Discovery — Spring Cloud’s implementation with Eureka
Related: API Gateway Pattern — API Gateway uses service discovery to route requests
Contrasts with: DNS — DNS resolves name → single IP (cached, slow to update); registry returns dynamic, health-filtered instance list

Edge Cases & Gotchas

Stale registry entries: Instances that crash without graceful shutdown (kill -9) leave stale entries — heartbeats eventually evict them
Registry SPOF: The registry itself must be highly available — run in cluster mode
Cache staleness: Client-cached instance lists may point to dead instances — use circuit breakers and retries
Bootstrap problem: Clients need to know registry location before they can discover services — use well-known DNS or static config
Multi-datacenter: Registry should prefer instances in the same datacenter/region (zone affinity) to reduce latency

Servlet vs JSP — Web Presentation Technologies Compared

2026-05-13T00:00:00.000Z

What’s Being Compared

Servlets and JSP are both Java web technologies for generating dynamic content, but they differ fundamentally in their orientation: Servlets are Java-centric (HTML embedded in Java code), while JSP is content-centric (Java embedded in HTML). The choice affects development team composition, maintenance, and separation of concerns.

The Core Tension

The tradeoff is between control (Servlets give full programmatic access to HTTP request/response) vs separation (JSP enables non-Java designers to maintain the view layer). Both compile to the same underlying servlet, but the development experience and team skill requirements differ.

Comparison

Dimension	Servlets	JSP
Nature	Java class with embedded HTML	HTML page with embedded Java
Best for	Request processing, business logic, API endpoints	Presentation, dynamic UI, form display
Java expertise	Required	Minimal (EL/JSTL)
Designer-friendly	No	Yes
Compilation	Direct .class	JSP→Servlet→.class
Performance	No translation overhead	First-access translation delay
Session management	HttpSession API	`session` implicit object
Error handling	try-catch in Java code	Error pages via `page` directive
Modern use	REST controllers (Spring MVC/Boot)	Template engines (Thymeleaf, React)

When to Use Servlets

Building REST APIs or web services (return JSON/XML, not HTML)
Request processing and routing logic
When the team is Java-heavy and output format is non-HTML
When you need full control over HTTP response headers and status codes

When to Use JSP

Generating dynamic HTML pages with complex layouts
Teams with UI designers who don’t write Java
Prototyping view-heavy applications quickly
Legacy enterprise applications with JSP-based views

The Insight

Servlets and JSP solve the same problem from opposite directions. In modern Spring applications, the distinction is largely moot: @RestController replaces servlets for APIs, and template engines (Thymeleaf, FreeMarker) replace JSP for views. The underlying lesson — separation of presentation from logic — is what matters, not the specific technology.

Connections

Servlets — Java-centric web component, compiled directly
JSP — HTML-centric web page, compiles to servlet
DispatcherServlet — Spring’s front controller unifying request handling
Spring Controller — Modern equivalent of Servlet for request handling
Spring MVC — Modern web framework that subsumes both Servlet and JSP patterns

spring-annotations

2026-05-13T00:00:00.000Z

The Problem

XML-based Spring configuration is verbose. Every bean declaration, property setting, and dependency wiring requires XML elements. As applications grow, XML files become unwieldy and hard to maintain. Developers need a more concise way to declare and configure beans directly in the code that defines them.

Core Idea

Spring annotations enable declarative bean definition and configuration directly in Java source code. Stereotype annotations (@Component, @Service, @Repository, @Controller) mark classes as Spring-managed beans. Configuration annotations (@Configuration, @Bean, @ComponentScan) replace XML configuration files with Java classes.

How It Works

Stereotype annotations: @Component (generic), @Service (business logic), @Repository (data access), @Controller (web) — all register the class as a Spring bean
Annotation scanning: @ComponentScan tells Spring to scan specified packages for stereotype-annotated classes
Java configuration: @Configuration classes contain @Bean methods that return objects to be managed as beans
Property injection: @Value("${property.name}") injects values from properties files
Bean definition: @Bean in @Configuration class defines a bean with full lifecycle control
Conditional beans: @Conditional, @Profile create beans only when specific conditions are met

Visual Explanation

Key Properties

Stereotype hierarchy: @Service, @Repository, @Controller are specializations of @Component with different semantics
Component scanning: Spring finds annotated classes via classpath scanning — no XML bean declarations needed
Java config: @Configuration + @Bean replaces XML entirely with compile-time-checked config
@Scope: Configures bean scope (singleton, prototype, request, etc.) on the bean class
@Lazy: Defers bean initialization until first use instead of at container startup
@Profile: Activates beans only in specific environments (dev, test, prod)

Connections

Built from: Spring IoC Container — Annotations are a configuration method for the container
Built from: Spring Framework — Annotations modernized Spring configuration
Related: Spring Autowiring — @Autowired works alongside stereotype annotations
Builds into: Spring MVC — @Controller, @RequestMapping are Spring MVC annotations
Related: Spring Boot — @SpringBootApplication combines @Configuration + @ComponentScan + @EnableAutoConfiguration

Edge Cases & Gotchas

Annotation scan scope: Without @ComponentScan pointing to the right package, @Service and friends do nothing
Ambiguous stereotypes: @Repository adds translation of persistence exceptions; @Service and @Component are functionally identical
Proxy mode: Annotations on methods only work when called through the Spring proxy — internal method calls bypass them
Annotation vs XML override: XML bean definitions can override annotation-based configurations if both are present

spring-aop-advice

2026-05-13T00:00:00.000Z

The Problem

Cross-cutting concerns need fine-grained control over when they execute — before a method runs, after it completes (success or failure), only on success, only on exception, or wrapping the method entirely. Each timing has different use cases and different access to method parameters, return values, and exceptions.

Core Idea

Spring AOP provides five advice types that define exactly when aspect code executes relative to the target method: @Before (pre-processing), @After (finally), @AfterReturning (post-processing on success), @AfterThrowing (error handling), and @Around (full control — can skip or modify method execution).

How It Works

@Before: Executes before the target method. Can access method arguments via JoinPoint.getArgs(). Cannot prevent method execution (unlike Around)
@After: Executes after the target method completes, regardless of outcome (like finally). Used for cleanup, auditing
@AfterReturning: Executes after successful return. Can access the return value via returning attribute. Not called if method throws
@AfterThrowing: Executes when the target method throws an exception. Can access the exception via throwing attribute
@Around: Most powerful. Wraps the target method entirely. ProceedingJoinPoint.proceed() invokes the target. Can modify arguments, catch exceptions, change return value, skip execution entirely

Visual Explanation

Key Properties

@Before: Read method args, perform validation or logging. Cannot abort method
@After: Cleanup, audit logging. Runs like finally block
@AfterReturning: Post-process return value (but can’t change it unless using Around). Access via returning = "result"
@AfterThrowing: Log or transform exceptions. Access via throwing = "ex"
@Around: Most flexible — modify args, catch exceptions, change return value, skip execution entirely
JoinPoint: All advice types (except Around) receive JoinPoint; Around receives ProceedingJoinPoint

Connections

Built from: Spring AOP — Advice types are the action component of aspects
Built from: Spring Framework — AOP advice is a core Spring AOP feature
Related: Try-Catch-Finally — Advice types mirror structured exception handling patterns
Builds into: Declarative Transactions — @Transactional is implemented via @Around advice
Related: Spring Security — Security annotations use @Before/@Around advice for auth checks

Edge Cases & Gotchas

@Around must call proceed(): If @Around advice doesn’t call proceed(), the target method never executes
Multiple aspects: Order is controlled by @Order annotation or Ordered interface
Return value modification: @AfterReturning can’t change the return value (only read it); use @Around to wrap and modify
Exception swallowing: @Around can catch and suppress exceptions — accidentally hiding errors
ProceedingJoinPoint: Only available in @Around advice; casting JoinPoint to ProceedingJoinPoint in other advice types throws ClassCastException

spring-aop

2026-05-13T00:00:00.000Z

The Problem

Cross-cutting concerns like logging, transaction management, security checking, and performance monitoring affect many parts of an application. Without AOP, these concerns are scattered across every method (logging everywhere), tangled with business logic, and hard to maintain consistently.

Core Idea

Aspect-Oriented Programming (AOP) in Spring allows separating cross-cutting concerns from business logic by defining “aspects” that automatically apply behavior at specified “join points.” Spring AOP uses proxy-based weaving (JDK dynamic proxies or CGLIB) to intercept method calls and apply aspects without modifying business code.

How It Works

Aspect: A modularized cross-cutting concern (e.g., @Aspect class with logging logic)
Join point: A specific point in program execution — in Spring AOP, always a method invocation
Advice: Action taken at a join point — @Before (before method), @After (after, regardless of outcome), @AfterReturning (after success), @AfterThrowing (after exception), @Around (wraps the method)
Pointcut: Expression that selects join points — execution(* com.example.service.*.*(..)) matches all methods in service package
Weaving: Spring creates a proxy of the target object and applies aspects at the matched join points
Proxy modes: JDK dynamic proxy (target implements an interface) or CGLIB proxy (target is a concrete class)

Visual Explanation

Key Properties

Proxy-based: Spring AOP is proxy-based, not bytecode weaving — applies only to Spring-managed beans
Method-level only: Only method execution join points; no field access or constructor interception
@AspectJ support: Annotation-based AOP using AspectJ pointcut expression syntax
Pointcut designators: execution(), within(), this(), target(), args(), @annotation()
XML config (legacy): Spring 1.2 old-style AOP with ProxyFactoryBean and interceptors
Auto-proxying: @EnableAspectJAutoProxy automatically creates proxies for @Aspect beans

Connections

Built from: Spring Framework — AOP is a core Spring module
Built from: Spring AOP Advice Types — The different advice types implement aspects
Builds into: Spring Security — Security annotations (@PreAuthorize) use Spring AOP
Builds into: Declarative Transactions — @Transactional uses Spring AOP
Contrasts with: EJB Container — EJB uses container-managed interception; Spring AOP is proxy-based

Edge Cases & Gotchas

Internal method calls: A method within the same class calling another method bypasses the proxy — AOP doesn’t apply
Final methods: CGLIB can’t override final methods — no AOP for final methods on classes without interfaces
Self-injection: Use @Autowired MyService self + @Lazy to enable AOP for internal calls
Performance: @Around advice adds overhead to every matched method — use judiciously
Proxy exposure: If the target casts this in its methods, it gets the raw object, not the proxy

spring-autowiring

2026-05-13T00:00:00.000Z

The Problem

Manually wiring bean dependencies in XML or @Bean methods becomes repetitive and error-prone as the number of beans grows. Each dependency requires an explicit <property> or @Bean method parameter. Developers want the container to resolve dependencies automatically based on type or name.

Core Idea

Autowiring is Spring’s automatic dependency resolution mechanism. The container inspects a bean’s constructor, setter, or field and automatically provides the matching dependency. The primary modes are: byType (default with @Autowired), byName (matching bean ID to field name), and explicit @Qualifier for disambiguation.

How It Works

@Autowired field injection: Container matches field type to a bean of that type in the context
Constructor injection (preferred): Container resolves constructor parameter types and provides matching beans
Setter injection: Container calls the setter with the resolved dependency after instantiation
Disambiguation: If multiple beans of the same type exist, @Primary marks the preferred one; @Qualifier("beanName") selects by name
Optional dependencies: @Autowired(required=false) — if no bean is found, leaves field as null
@Resource: JSR-250 annotation, resolves by bean name (field name) first, then by type

Visual Explanation

Key Properties

Mode byType: Default behavior — Spring matches by field/constructor parameter type
Mode byName: Matches field name to bean ID (used with @Resource)
@Primary: Marks a bean as the preferred choice when multiple candidates exist
@Qualifier: Selects a specific bean by name when type alone is ambiguous
Constructor injection preferred: Immutable dependencies, required by default, better testability
Field injection: Simplest but makes testing harder (no way to set field without reflection)

Connections

Built from: Spring IoC Container — Autowiring is the DI resolution mechanism within the container
Built from: Spring Framework — Autowiring is a core Spring DI feature
Related: Spring Bean Lifecycle — Autowiring executes during the dependency injection phase
Related: Spring Annotations — @Autowired, @Qualifier, @Primary are Spring annotations
Contrasts with: EJB Context — EJB’s JNDI lookup is explicit; Spring autowiring is implicit

Edge Cases & Gotchas

NoUniqueBeanDefinitionException: Multiple beans of same type without @Primary or @Qualifier — the most common autowiring error
Field injection in unit tests: Need reflection or Spring test runner; constructor injection avoids this entirely
Circular dependency with constructor injection: Unresolvable — use @Lazy on one side or switch to setter injection
@Autowired on final fields: Fails because Spring uses reflection to set fields but final fields can’t be set via reflection after construction

spring-bean-lifecycle

2026-05-13T00:00:00.000Z

The Problem

Enterprise applications need fine-grained control over object lifecycle — when objects are created, how they’re initialized, what happens after all dependencies are set, and how they’re cleaned up. Different use cases require different sharing strategies (singleton for stateless services, prototype for stateful objects).

Core Idea

The Spring Bean Lifecycle defines the birth-to-death phases every managed bean goes through: instantiation → dependency injection → initialization → ready → destruction. Bean scopes determine how long a bean lives and how many instances are created. Custom scopes can be defined for special use cases.

How It Works

Instantiation: Container creates the bean instance via constructor
Dependency injection: Container injects dependencies (via constructor, setter, or field)
Awareness callbacks: If bean implements BeanNameAware, BeanFactoryAware, ApplicationContextAware, container calls them
Pre-initialization: BeanPostProcessor.postProcessBeforeInitialization() — container-wide hooks
Initialization: @PostConstruct method → InitializingBean.afterPropertiesSet() → custom init-method
Post-initialization: BeanPostProcessor.postProcessAfterInitialization() — proxy creation happens here (AOP)
Ready: Bean is fully initialized and available for use
Destruction: @PreDestroy method → DisposableBean.destroy() → custom destroy-method
Scopes: singleton (one per container), prototype (new per request), request/ session/application (web contexts), custom

Visual Explanation

Key Properties

Singleton scope: Default; one instance per IoC container; ideal for stateless services
Prototype scope: New instance every time the bean is requested; use for stateful objects
Web scopes: request (one per HTTP request), session (one per HTTP session), application (one per ServletContext)
Custom scopes: Define custom scope logic (e.g., thread-scoped, tenant-scoped) via Scope interface
BeanPostProcessor: Container-wide hooks that run for every bean — critical for AOP proxy creation
Lifecycle callbacks: Three ways per phase: annotations (@PostConstruct/@PreDestroy), interfaces, custom init/destroy method

Connections

Built from: Spring IoC Container — The container manages the entire bean lifecycle
Built from: Spring Framework — Lifecycle management is a core Spring feature
Related: Spring Autowiring — Dependency injection occurs during the lifecycle’s second phase
Related: Stateless Bean Lifecycle — EJB containers also manage bean lifecycles, but with different phases
Contrasts with: Stateful Bean Lifecycle — EJB stateful beans have passivation/activation; Spring beans don’t

Edge Cases & Gotchas

Prototype destruction: Container does NOT call destroy() on prototype beans — you must clean them up manually
Circular dependency: Constructor injection + circular dependency causes BeanCurrentlyInCreationException; use setter injection or @Lazy
PostConstruct in proxy: @PostConstruct in a proxy-wrapped bean runs on the target, not the proxy
Scope mismatch: Injecting a shorter-lived bean (request) into a longer-lived bean (singleton) requires scoped proxy (@Scope(proxyMode=ScopedProxyMode.TARGET_CLASS))

spring-boot-actuator

2026-05-13T00:00:00.000Z

The Problem

Production applications need runtime visibility: Are they healthy? How much memory are they using? What’s the request rate? Are there active database connections? Without built-in monitoring, developers resort to SSH access, custom scripts, or third-party agents — which are inconsistent and fragile.

Core Idea

Spring Boot Actuator provides production-ready HTTP endpoints for monitoring and managing Spring Boot applications. Endpoints expose health information, metrics, environment properties, thread dumps, and more. It integrates with Micrometer for exporting metrics to monitoring systems (Prometheus, Graphite, Datadog).

How It Works

Actuator endpoints: /actuator/health (app health), /actuator/metrics (JVM and app metrics), /actuator/info (custom app info), /actuator/env (environment properties), /actuator/loggers (log level management)
Health indicators: Built-in indicators check database connectivity, disk space, Redis, Elasticsearch, etc. — all aggregated into the /health response
Micrometer: Actuator’s metrics facade sends metrics to various monitoring systems (Prometheus, Graphite, InfluxDB)
Security: Actuator endpoints are secured by default (Spring Security integration); sensitive endpoints restricted to authenticated users
Custom endpoints: @Endpoint annotation to create custom actuator endpoints with @ReadOperation, @WriteOperation, @DeleteOperation

Visual Explanation

Key Properties

Built-in endpoints: 15+ production endpoints (health, metrics, env, loggers, heapdump, threaddump, mappings)
Health aggregation: Downstream service health indicators aggregated into overall UP/DOWN status
Micrometer integration: Vendor-neutral metrics facade; binders for JVM, CPU, file descriptors, logback, HikariCP
Audit events: AuditEventRepository captures authentication and other security events
Custom info: /info endpoint exposes any properties under info.* in application.properties
Log level management: Change log levels at runtime via POST to /actuator/loggers/{name} — no restart needed

Connections

Built from: Spring Boot — Actuator is a Spring Boot module for production monitoring
Related: Spring Boot Auto-Configuration — Actuator auto-configures endpoints based on available dependencies
Related: Spring Boot REST API — Actuator endpoints are themselves REST APIs
Contrasts with: EJB Context — EJB provides programmatic context; Boot Actuator provides HTTP-accessible monitoring

Edge Cases & Gotchas

Sensitive info in /env: Environment values containing passwords/keys are sanitized by default; configure additional sanitization keys
Endpoint exposure: By default, only /health and /info are exposed via HTTP — use management.endpoints.web.exposure.include=* to expose all
Security: Exposing /actuator/shutdown without authentication allows anyone to stop the application
Performance impact: High-frequency metrics collection (every 1ms) can impact performance; use appropriate export intervals
Health cascading: If a downstream service is DOWN, the application reports DOWN — configure health indicator thresholds

spring-boot-auto-configuration

2026-05-13T00:00:00.000Z

The Problem

Spring applications need many infrastructure beans: DataSource, EntityManagerFactory, TransactionManager, DispatcherServlet, ViewResolver, MessageConverter. Manually configuring all of them is repetitive, error-prone, and project-specific — the same patterns repeat across every Spring project.

Core Idea

Auto-configuration is Spring Boot’s mechanism for automatically creating and configuring beans based on dependencies on the classpath. It uses @Conditional annotations to apply configuration only when specific classes, beans, or properties are present. Starters are curated dependency descriptors that trigger auto-configuration for a specific technology.

How It Works

@EnableAutoConfiguration: Triggers scanning of META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports
Conditional evaluation: Each auto-configuration class has @ConditionalOnClass, @ConditionalOnMissingBean, @ConditionalOnProperty conditions
Example: If DataSource class is on classpath AND no DataSource bean is defined, Boot auto-creates one from application.properties
@ConditionalOnClass: Configuration applies only if specific classes exist on classpath (e.g., HSQL Driver)
@ConditionalOnMissingBean: Don’t override user-defined beans — user’s @Bean takes priority
@ConditionalOnProperty: Enable/disable configuration via properties (e.g., spring.jpa.hibernate.ddl-auto)
Override mechanism: User defines a @Bean of the same type → auto-configuration backs off

Visual Explanation

Key Properties

Conditional annotations: @ConditionalOnClass, @ConditionalOnMissingBean, @ConditionalOnProperty, @ConditionalOnResource, etc.
Starter dependencies: spring-boot-starter-web, spring-boot-starter-data-jpa, spring-boot-starter-security — each pulls the transitive deps needed
Auto-configuration report: Enable --debug to see which auto-configurations applied and which were skipped
Custom starter: Create spring-boot-starter-* with auto-configuration module + starter POM
Property binding: @ConfigurationProperties binds properties to structured Java objects

Connections

Built from: Spring Boot — Auto-configuration is the core feature of Spring Boot
Related: Spring Boot Actuator — Actuator’s auto-configuration adds health, metrics endpoints
Related: Spring Boot REST API — Web auto-configuration sets up embedded Tomcat + Jackson + MVC
Contrasts with: EJB Deployment Descriptor — EJB uses declarative XML; Spring Boot uses classpath-based conditions
Builds into: Spring Data JPA — Spring Boot auto-configures DataSource and JPA repos

Edge Cases & Gotchas

Hidden configuration: Auto-configuration can create beans you didn’t expect — use spring-boot:run --debug to see the report
Override confusion: Simply adding your own @Bean of the same type disables auto-configuration — sometimes intentionally
Starter conflicts: Conflicting starters (e.g., two embedded DBs on classpath) can cause startup failures
Exclusion: Exclude auto-configuration classes with @SpringBootApplication(exclude = DataSourceAutoConfiguration.class)
Performance: Auto-configuration evaluation happens at startup — hundreds of conditional checks can slow cold starts

spring-boot-rest-api

2026-05-13T00:00:00.000Z

The Problem

Modern applications expose APIs for frontend clients, mobile apps, and third-party integrations. Building RESTful APIs requires mapping HTTP methods to operations, serializing/deserializing JSON, handling status codes, and managing request/response formats. Without good tooling, this involves significant boilerplate.

Core Idea

Spring Boot makes REST API development effortless by combining @RestController for request handling, auto-configured Jackson for JSON serialization, embedded Tomcat for serving, and Actuator for monitoring. A single @SpringBootApplication class and a few controller methods produce a production-ready REST API.

How It Works

@RestController: @Controller + @ResponseBody — every method returns data (JSON/XML), not view names
Request mapping: @GetMapping, @PostMapping, @PutMapping, @DeleteMapping map HTTP verbs and URLs
Request binding: @PathVariable, @RequestParam, @RequestBody bind request data to method parameters
Response serialization: Jackson (auto-configured) serializes Java objects to JSON; @JsonIgnore, @JsonProperty control output
Status codes: @ResponseStatus(HttpStatus.CREATED) or ResponseEntity for full control
Exception handling: @RestControllerAdvice provides consistent JSON error responses across all endpoints
Documentation: Spring Boot integrates with Swagger/OpenAPI for auto-generated API docs

Visual Explanation

Key Properties

RESTful mapping: One annotation per HTTP verb — @GetMapping, @PostMapping, @PutMapping, @DeleteMapping, @PatchMapping
Content negotiation: Jackson serializes to JSON by default; XML if Jackson XML extension is on classpath
ResponseEntity: Full control over status, headers, and body — ResponseEntity.created(location).body(savedUser)
Request validation: @Valid + BindingResult for request body validation
HATEOAS: Spring HATEOAS adds link support for hypermedia-driven APIs
Testing: MockMvc and WebTestClient for comprehensive REST API testing

Connections

Built from: Spring Boot — Boot auto-configures the web stack for REST APIs
Built from: Spring Controller — @RestController is a specialized @Controller
Related: JAX-RPC — JAX-RPC is XML-based SOAP; Spring Boot REST is JSON-based, lighter
Builds into: Java Microservices — REST APIs are the communication backbone of microservices
Related: HTTP Protocol — REST APIs use HTTP semantics (methods, status codes, headers)

Edge Cases & Gotchas

Circular references: Bidirectional JPA relationships cause infinite JSON serialization — use @JsonIgnore or @JsonManagedReference/@JsonBackReference
Global prefix: All APIs under /api/v1/ — set server.servlet.context-path or use RequestMapping at class level
Content-type mismatch: Client sends wrong Content-Type → 415 Unsupported Media Type
Versioning: URL path versioning (/v1/users) vs header versioning (Accept: application/vnd.company.v1+json)
CORS: Browsers block cross-origin requests; @CrossOrigin or WebMvcConfigurer.addCorsMappings() to allow

spring-boot

2026-05-13T00:00:00.000Z

The Problem

Setting up a Spring application requires extensive configuration: choosing a servlet container, configuring DispatcherServlet, setting up view resolvers, managing dependency versions, writing XML/Java config — all before writing any business code. This setup overhead delays development and varies across projects.

Core Idea

Spring Boot is an opinionated framework on top of Spring that eliminates boilerplate configuration through auto-configuration and starter dependencies. It embeds Tomcat/Jetty/Undertow, provides sensible defaults for all Spring modules, and enables production-ready features (metrics, health checks) with minimal effort.

How It Works

@SpringBootApplication: Combines @Configuration, @ComponentScan, @EnableAutoConfiguration
Auto-configuration: Spring Boot detects libraries on the classpath and automatically configures beans — e.g., if H2 is on classpath, auto-configures a DataSource
Starters: Curated dependency descriptors (spring-boot-starter-web includes Spring MVC + embedded Tomcat + Jackson)
Embedded server: Application runs as a standalone JAR with embedded Tomcat — no WAR deployment needed
Externalized configuration: application.properties or application.yml with environment-specific profiles
Actuator: Production endpoints for health, metrics, environment, loggers, thread dumps

Visual Explanation

Key Properties

Opinionated defaults: Sensible configurations chosen automatically based on classpath contents
Standalone JAR: Run with java -jar app.jar — no external web server needed
Starters: ~50 curated dependency sets; one-liner in build file replaces pages of dependency management
Actuator: Built-in production monitoring: health, metrics, environment, loggers
Externalized config: Properties, YAML, environment variables, command-line arguments — with precedence order
Spring Boot CLI: Groovy-based command-line tool for rapid prototyping (optional)

Connections

Built from: Spring Framework — Spring Boot builds on and auto-configures Spring Framework
Built from: Spring Boot Auto-Configuration — The auto-configuration mechanism drives Spring Boot
Builds into: Spring Boot Actuator — Actuator provides production monitoring
Builds into: Spring Boot REST API — REST APIs are a primary use case for Spring Boot
Related: Spring MVC — Spring Boot auto-configures Spring MVC with embedded server
Contrasts with: EJB-JAR File — EJB requires an application server; Spring Boot is self-contained

Edge Cases & Gotchas

Auto-configuration ignorance: Auto-configuration applies conditionally — if you define your own bean, Boot’s default backs off
Fat JAR size: Spring Boot executable JARs include all dependencies — can be 20MB+; use Docker layers for efficient deployment
DevTools: spring-boot-devtools enables live reload but should NEVER be included in production builds
Context path: By default, server runs on root context; set server.servlet.context-path=/myapp in properties
Profile-specific config: application-dev.properties overrides application.properties when spring.profiles.active=dev

spring-cloud-api-gateway

2026-05-13T00:00:00.000Z

The Problem

In a microservices architecture, clients would need to know the location of every service, handle authentication for each service, and manage cross-cutting concerns (rate limiting, logging) individually. This creates tight coupling between clients and services, and duplicates security/observability logic.

Core Idea

Spring Cloud Gateway is an API Gateway built on Spring WebFlux (Reactive). It acts as a single entry point for all client requests, routing them to the appropriate microservice based on path, headers, or other predicates. It handles cross-cutting concerns — authentication, rate limiting, header transformation — in one place.

How It Works

Route definition: Routes match incoming requests using predicates (path, method, header, query param)
Predicate matching: Path=/users/** matches all requests starting with /users
Filter chains: Before routing to the service, the request passes through a filter chain: authentication, rate limiting, header modification
Service routing: Gateway forwards the request to the target service (discovered via Eureka or configured URI)
Response filters: On the return path, filters modify the response (add headers, transform body)
WebFlux: Built on reactive Netty, not Tomcat — non-blocking I/O for high throughput

Visual Explanation

Key Properties

Reactive: Built on Spring WebFlux, not Servlet API — non-blocking, high concurrency
Route predicates: Path, Method, Header, Query, Cookie, Host, RemoteAddr, Weight
Filters: AddRequestHeader, AddResponseHeader, CircuitBreaker, Retry, RateLimiter, RequestRateLimiter
Service discovery integration: Automatically resolves service names via Eureka / LoadBalancer
Custom filters: Implement GatewayFilter or GlobalFilter interfaces for custom logic
Circuit breaking: Integrates with Resilience4j for downstream service failure protection

Connections

Built from: Spring Cloud — Gateway is a Spring Cloud module for edge services
Built from: Spring Cloud Service Discovery — Gateway uses Eureka to find service instances
Related: Spring Boot — Gateway is auto-configured via Spring Boot
Builds into: Java Microservices — API Gateway is a core component of microservice architecture
Contrasts with: Servlets — Servlets are blocking I/O; Gateway uses reactive non-blocking WebFlux

Edge Cases & Gotchas

WebFlux vs MVC: Gateway runs on Netty (WebFlux) — can’t use @Controller, RestTemplate; use WebClient instead
WebSocket support: Gateway supports WebSocket proxying via ws: / wss: route URIs
CORS: Gateway must handle CORS at the edge — configure spring.cloud.gateway.globalcors
Latency: Each filter adds latency — keep filter chains lean
Gateway as SPOF: The gateway is a single point of entry — deploy multiple instances behind a load balancer

spring-cloud-service-discovery

2026-05-13T00:00:00.000Z

The Problem

In a microservices architecture, service instances come and go dynamically — scaled up, down, or failed. Hard-coding service URLs (e.g., http://192.168.1.5:8080) makes the system brittle. Services need a dynamic registry to discover each other’s locations without manual configuration.

Core Idea

Spring Cloud Service Discovery uses a service registry (Netflix Eureka) where each microservice registers its network location on startup and periodically sends heartbeats. Clients query the registry by logical service name (e.g., user-service) to get available instances and distribute requests using client-side load balancing.

How It Works

Eureka Server: A standalone service that maintains a registry of all available service instances. Services register their host, port, health status
Service registration: Each microservice, annotated with @EnableEurekaClient, registers with the Eureka server on startup
Heartbeat (renew): Registered services send periodic heartbeats (default 30s) to signal they’re alive. Missed heartbeats → instance is evicted
Service discovery: Clients use @LoadBalanced RestTemplate or Spring Cloud OpenFeign to call services by logical name — e.g., http://user-service/api/users
Load balancing: Spring Cloud LoadBalancer intercepts the logical name, queries Eureka for instances, and selects one (round-robin, random, etc.)
Client-side vs Server-side: Client-side (Ribbon/LoadBalancer) — client chooses instance; Server-side — load balancer (Nginx, AWS ELB) distributes requests

Visual Explanation

Key Properties

Eureka Server: Central registry; each service registers its metadata (host, port, health URL)
@EnableEurekaClient: Annotation to make a Spring Boot service a Eureka client
Heartbeat mechanism: Periodic renewal (30s); eviction after missed heartbeats (90s default)
Client-side load balancing: Spring Cloud LoadBalancer selects instance; supports round-robin, weighted, custom strategies
Self-preservation mode: Eureka stops evicting instances during network partition — favors availability over consistency
OpenFeign: Declarative HTTP client — @FeignClient("user-service") interface with @GetMapping("/api/users")

Connections

Built from: Spring Cloud — Service discovery is a core Spring Cloud feature
Built from: Spring Boot — Eureka client auto-configuration via Spring Boot
Related: Spring Cloud API Gateway — Gateway routes requests using service discovery
Builds into: Java Microservices — Service discovery is essential for microservice communication
Contrasts with: DNS — DNS resolves hostname → IP; service discovery resolves service name → dynamic IP list

Edge Cases & Gotchas

Eureka AP vs CP: Eureka favors Availability over Consistency (AP in CAP theorem) — during network partitions, stale instances remain
Slow startup: First call after startup may fail because the client’s registry is not yet populated — use retries
Zone affinity: Eureka supports zones for regional deployment — clients prefer instances in the same zone
Default port: Eureka server runs on port 8761 by default — change via server.port in configuration
Stale cache: Client caches the registry — use appropriate refresh intervals or manual eviction in failure scenarios

spring-cloud

2026-05-13T00:00:00.000Z

The Problem

Building cloud-native microservices requires solving distributed system challenges: service discovery (how do services find each other?), load balancing (which instance to call?), distributed configuration (how to manage config across services?), and fault tolerance (what happens when a service is down?).

Core Idea

Spring Cloud provides a suite of tools for building cloud-native microservices. It integrates with Netflix OSS (Eureka for service discovery, Ribbon for load balancing, Hystrix for circuit breaking), provides distributed configuration with Spring Cloud Config, API gateway with Spring Cloud Gateway, and distributed tracing with Sleuth/Zipkin.

How It Works

Service discovery: Spring Cloud Netflix Eureka — services register with Eureka server, clients discover via service name
Load balancing: Spring Cloud LoadBalancer (replaced Netflix Ribbon) — client-side load balancing across service instances
API Gateway: Spring Cloud Gateway — routes requests to appropriate services, handles cross-cutting (auth, rate limiting)
Distributed config: Spring Cloud Config Server — external configuration stored in Git, served to all services
Distributed tracing: Spring Cloud Sleuth + Zipkin — trace IDs propagate across service calls, visualized in Zipkin dashboard
Fault tolerance: Resilience4j (replaced Hystrix) — circuit breakers, retries, bulkheads, rate limiters

Visual Explanation

Key Properties

Service discovery: Eureka server for service registration and discovery; Spring Cloud LoadBalancer for client-side load balancing
API Gateway: Route requests, add headers, rate-limiting, authentication, circuit breaking at edge
Configuration management: Externalized, version-controlled configuration via Spring Cloud Config (Git backend)
Circuit breakers: Resilience4j for fault tolerance — prevents cascading failures
Distributed tracing: Sleuth adds trace/span IDs; Zipkin visualizes request flows across services
Cloud platform support: AWS (EC2, S3, SQS), GCP, Azure integrations via Spring Cloud for each provider

Connections

Built from: Spring Boot — Spring Cloud builds on Spring Boot’s auto-configuration
Built from: Spring Framework — Spring Cloud uses Spring’s DI and configuration
Related: Spring Cloud Service Discovery — Eureka and LoadBalancer enable service-to-service calls
Related: Spring Cloud API Gateway — Gateway is the entry point for all microservices
Builds into: Java Microservices — Spring Cloud provides the infrastructure for microservices
Contrasts with: J2EE Specification — J2EE is monolithic; Spring Cloud is cloud-native microservices

Edge Cases & Gotchas

Eureka self-preservation: In network partitions, Eureka keeps its registrations (AP over CP) — stale entries during real failures
Config server SPOF: Config server is a single point of failure — make it highly available or use native cloud config services
Gateway latency: Every request goes through the gateway, adding latency — avoid putting heavy logic in gateway filters
Bootstrap context: Spring Cloud uses bootstrap.yml (loaded before application.yml) for config server location — easy to misconfigure
Version compatibility: Spring Cloud releases are coordinated (2020.0.x, 2021.0.x, etc.) — Spring Boot version must match the cloud release train

spring-controller

2026-05-13T00:00:00.000Z

The Problem

Web application logic needs to respond to specific URL patterns, extract parameters from requests, and return data or views to the client. Without a structured approach, each page would manually parse URLs, manage HTTP methods, and construct responses — duplicating effort across handlers.

Core Idea

Spring Controllers are @Controller-annotated classes whose methods handle specific URL patterns and HTTP methods, defined via @RequestMapping and its shortcut annotations (@GetMapping, @PostMapping, etc.). @RestController combines @Controller with @ResponseBody for REST APIs, automatically serializing return values to JSON or XML.

How It Works

@RequestMapping: Maps HTTP method + URL path to a controller method — e.g., @GetMapping("/users/{id}")
Method parameters: Automatically bound from request: @RequestParam (query params), @PathVariable (URL segments), @RequestBody (JSON body), @ModelAttribute (form data)
Return types: String (view name), ModelAndView, @ResponseBody (JSON/XML), ResponseEntity (full control)
@RestController: All methods default to @ResponseBody; no view resolution — returns data directly
@Controller vs @RestController: @Controller returns view names; @RestController returns data (JSON/XML)

Visual Explanation

Key Properties

@RequestMapping shortcuts: @GetMapping, @PostMapping, @PutMapping, @DeleteMapping, @PatchMapping
@PathVariable: Binds URL template variables — @GetMapping("/users/{id}") + (@PathVariable Long id)
@RequestParam: Binds query parameters with optional default values and required flag
@RequestBody: Deserializes request body (JSON/XML) to Java object using HttpMessageConverter
@ResponseBody: Serializes return value directly to HTTP response body
@ResponseStatus: Sets HTTP status code on successful method execution

Connections

Built from: Spring MVC — Controllers are the handler components in Spring MVC
Built from: DispatcherServlet — DispatcherServlet invokes controller methods
Related: Spring Form Handling — @ModelAttribute binds form data to model objects
Related: Spring MVC Exception Handling — @ExceptionHandler in controllers
Contrasts with: Servlets — Servlets extend HttpServlet; Spring Controllers are POJOs with annotations

Edge Cases & Gotchas

@RequestParam required=true by default: Missing required param returns 400 — use required=false or defaultValue
@PathVariable vs @RequestParam: Path variables identify resources; request params filter/ paginate
@ResponseBody + String: Returns the string itself, not a view name — common confusion with @Controller
Method-level vs class-level @RequestMapping: Class-level is the prefix; method-level defines the specific endpoint

spring-data-jpa

2026-05-13T00:00:00.000Z

The Problem

Implementing data access layers requires writing repetitive DAO (Data Access Object) code: creating queries, managing EntityManager, handling transactions, mapping results. Even with Hibernate, developers still write CRUD methods for every entity — findAll, findById, save, delete, plus custom query methods.

Core Idea

Spring Data JPA is a data access framework that eliminates boilerplate repository code. By extending JpaRepository (or CrudRepository), interfaces automatically inherit CRUD methods without implementation. Custom queries are derived from method names (e.g., findByLastName(String name)) or defined via @Query.

How It Works

Repository interface: public interface UserRepository extends JpaRepository<User, Long> — no implementation needed
Inherited methods: findAll(), findById(), save(), delete(), count(), existsById() — all auto-implemented
Derived query methods: Method names like findByEmailAndActive(String email, boolean active) — Spring Data parses the name and generates JPQL
@Query: Custom JPQL or native SQL queries for complex operations: @Query("SELECT u FROM User u WHERE u.email = :email")
Pagination: Pageable parameter returns Page<T> with total count, sorting, and pagination metadata
Sorting: Sort.by("lastName").ascending() or findAll(Sort.by("lastName"))

Visual Explanation

Key Properties

Interface-based: No implementation to write — Spring Data generates the proxy at runtime
Derived queries: Parse method naming conventions: findBy, readBy, countBy, deleteBy
Query methods: Support AND, OR, Between, LessThan, GreaterThan, Like, In, IgnoreCase, OrderBy
Pagination: Pageable parameter → Page<T> result with total elements, total pages, sorting
Sorting: Sort.by() or Pageable with Sort; also findAll(Sort.by("field"))
Custom queries: @Query("...") for JPQL; @Query(value = "...", nativeQuery = true) for native SQL
Modifying queries: @Modifying + @Query for UPDATE/DELETE operations

Connections

Built from: Spring Boot — Spring Boot auto-configures DataSource, JPA, and repository scanning
Built from: JDBC — Spring Data JPA ultimately uses JDBC for database access
Built from: Hibernate ORM Framework — Hibernate is the default JPA provider for Spring Data JPA
Related: JpaRepository — The core repository interface in Spring Data JPA
Related: JPA Query Methods — Derived query method naming conventions
Related: JPA Pagination and Sorting — Paging and sorting with Spring Data JPA

Edge Cases & Gotchas

Derived method explosion: Complex queries with many conditions produce unwieldy method names — use @Query instead
N+1 with findAll: Default findAll fetches associations lazily — consider @EntityGraph or JOIN FETCH in @Query
Transaction boundaries: Repository methods are transactional by default, but service-layer transactions should wrap multiple repo calls
Proxy limitation: Repository proxies can’t intercept internal method calls (method calls within the same class bypass the proxy)

spring-form-handling

2026-05-13T00:00:00.000Z

The Problem

HTML forms submit data that must be extracted, validated, bound to objects, and re-displayed with error messages on failure. Manual form handling requires tedious request parameter extraction, field-by-field validation, and error tracking — all duplicated across every form in the application.

Core Idea

Spring MVC provides comprehensive form handling: @ModelAttribute binds form fields to Java objects, @Valid triggers Bean Validation annotations, and BindingResult captures validation errors for display in the view. Spring form tags (<form:form>, <form:input>, <form:errors>) integrate with the model for seamless two-way binding.

How It Works

Form backing object: A Java bean (POJO) holds form data; added to model via @ModelAttribute
GET request: Controller adds empty/ pre-populated form object to model, returns form view
Form submission: POST request with form fields → Spring binds fields to @ModelAttribute parameters
Validation: @Valid on the parameter triggers annotation validation; errors go to BindingResult (must be immediately after the validated parameter)
Error handling: If BindingResult.hasErrors(), return to form view — errors display via <form:errors>
Success: If no errors, process data (save to DB) and redirect (POST-Redirect-GET pattern)

Visual Explanation

Key Properties

@ModelAttribute: Binds form fields to Java object fields by name match
@Valid / @Validated: Triggers Bean Validation (JSR-380) annotations like @NotBlank, @Email, @Size
BindingResult: Must immediately follow @Valid parameter; holds field and global errors
Spring form tags: <form:form>, <form:input>, <form:errors> — automatically populate and display errors
POST-Redirect-GET: Prevents duplicate form submission on refresh by redirecting after successful POST
Type conversion: Automatic conversion from String (form field) to int, long, date, etc.

Connections

Built from: Spring MVC — Form handling is part of Spring MVC’s web functionality
Built from: Spring Controller — Controller methods handle form GET and POST
Related: Spring MVC Exception Handling — Validation errors are distinct from exceptions
Related: Try-Catch-Finally — BindingResult tracks validation errors similarly to structured error collection

Edge Cases & Gotchas

BindingResult position: Must immediately follow the @Valid parameter — any fields between them cause binding failure
Errors on GET: First GET request has no BindingResult — use separate method or check if it’s a rebind
Nested properties: @Valid on nested objects requires cascading validation (@Valid on the nested field)
Conversion errors: Type mismatch (e.g., “abc” for int field) goes to BindingResult as a FieldError
Custom validators: Implement Validator interface and register; or use @Pattern for simple regex validation

spring-framework

2026-05-13T00:00:00.000Z

The Problem

Enterprise Java development requires handling cross-cutting concerns (transactions, security, logging) alongside business logic. Without a framework, these concerns get scattered across the codebase (cross-cutting) and tangled with business code, making applications hard to develop, test, and maintain.

Core Idea

Spring is a lightweight, modular Java application framework centered on Inversion of Control (IoC) and Dependency Injection (DI). It provides infrastructure for managing objects (beans), wiring dependencies, and integrating with enterprise services (transactions, persistence, messaging, web) through a consistent programming model.

How It Works

Bean container: Spring’s IoC container (ApplicationContext) manages object creation, wiring, and lifecycle
Configuration metadata: Beans are defined via XML, annotations, or Java config (@Configuration)
Dependency Injection: The container injects dependencies into beans at construction time, eliminating new calls
Aspect-Oriented Programming: Spring AOP weaves cross-cutting concerns (transactions, security) into beans without modifying business code
Modular architecture: Spring is organized into modules: Core, MVC, Data, Security, Cloud, Boot — use what you need

Visual Explanation

Key Properties

Lightweight: No application server required; runs in any JVM with a servlet container (Tomcat)
POJO-based: Business objects are plain Java objects with no Spring coupling (except annotations)
Non-invasive: Application code doesn’t extend Spring classes or implement Spring interfaces
Modular: Choose only the modules your application needs
Testable: DI makes unit testing trivial — mock dependencies can be injected in tests
Integration: First-class support for Hibernate, JPA, JDBC, JMS, JTA, JNDI

Connections

Built from: Spring IoC Container — Core of Spring, manages beans and DI
Builds into: Spring MVC — Web framework built on Spring Core
Builds into: Spring Boot — Auto-configuration on top of Spring Framework
Builds into: Spring Security — Security built on Spring AOP and DI
Related: Component Architecture & SOA — Both Spring and EJB address component-based enterprise development
Contrasts with: EJB Session Bean — Spring beans are lighter, no EJB container needed

Edge Cases & Gotchas

Configuration hell: Too many XML/annotation configurations can become as hard to manage as the problems Spring solves
Circular dependencies: Bean A depends on B which depends on A causes container startup failure; use setter injection or @Lazy
Proxy limitations: Spring AOP (JDK dynamic proxies) only intercepts public method calls on Spring-managed beans
Over-autowiring: Auto-wiring everything makes dependency graphs implicit and hard to trace

spring-ioc-container

2026-05-13T00:00:00.000Z

The Problem

In traditional Java applications, each object creates its own dependencies using new — tightly coupling classes to their collaborators. This coupling makes it hard to swap implementations, test in isolation, or change application behavior without editing source code.

Core Idea

The Spring IoC (Inversion of Control) Container is responsible for instantiating, configuring, and managing the lifecycle of Java objects (beans). Instead of objects creating their dependencies, the container creates everything and injects dependencies into objects. Two container types exist: BeanFactory (basic) and ApplicationContext (feature-rich).

How It Works

BeanFactory: The simplest container providing basic DI support. Lazy-initializes beans by default. Suitable for resource-constrained environments (mobile, applets)
ApplicationContext: Extends BeanFactory with enterprise features: event publishing, message i18n, AOP integration, declarative startup, and web application support. Eager-initializes singletons by default. Used in virtually all Spring applications
Configuration: Beans defined via XML (<bean>), annotations (@Component, @Service), or Java config (@Bean in @Configuration class)
Instantiation: Container reads configuration, validates bean definitions, resolves dependencies, and creates bean instances
Injection: Dependencies injected via constructor, setter, or field (using @Autowired)

Visual Explanation

Key Properties

Inversion of Control: Container controls bean lifecycle, not the application code
Dependency Injection: Dependencies provided automatically; objects don’t look them up
Lazy vs Eager: BeanFactory lazy-initializes; ApplicationContext eagerly initializes singletons
Bean scopes: singleton (default), prototype, request, session, application, websocket
Lifecycle callbacks: @PostConstruct, @PreDestroy, InitializingBean, DisposableBean

Connections

Built from: Spring Framework — IoC container is the core of Spring
Builds into: Spring Bean Lifecycle — The container manages every phase of a bean’s lifecycle
Builds into: Spring Autowiring — Autowiring is the DI resolution mechanism within the container
Related: EJB Context — Both provide access to container services
Contrasts with: EJB Home Interface — EJB uses JNDI lookups; Spring uses DI

Edge Cases & Gotchas

Startup cost: ApplicationContext initialization scans classpath, creates all singletons — can be slow with many beans
Memory: Eager initialization means all singleton beans stay in memory even if unused in the current request
BeanFactory vs ApplicationContext: Never use raw BeanFactory in modern Spring unless memory is constrained; ApplicationContext is always preferred
Configuration precedence: Java config > annotations > XML — mixing them requires understanding the override order

spring-jdbc-template

2026-05-13T00:00:00.000Z

The Problem

Raw JDBC requires manually managing every step of database access: getting a connection, creating a statement, setting parameters, iterating a ResultSet, handling checked SQLExceptions, and closing resources in finally blocks. A simple query becomes 15+ lines of repetitive, error-prone boilerplate.

Core Idea

Spring JDBC Template provides a template-based API that eliminates JDBC boilerplate. JdbcTemplate wraps the JDBC workflow: it handles connection acquisition, statement creation, parameter binding, result extraction, and cleanup. Developers provide only the SQL and the logic to map results to objects.

How It Works

JdbcTemplate: Core class wrapping JDBC — execute query/update with automatic resource management
NamedParameterJdbcTemplate: Uses named parameters (:name) instead of positional (?) — more readable, especially with many parameters
RowMapper: (ResultSet rs, int rowNum) → T maps a result set row to a domain object
ResultSetExtractor: For custom result extraction (e.g., building a Map from multiple rows)
SQL scripts: ResourceDatabasePopulator or ScriptUtils for executing SQL scripts during testing or setup

Visual Explanation

Key Properties

JdbcTemplate: Simplest template — positional ? parameters, automatic resource cleanup
NamedParameterJdbcTemplate: Named :param parameters, better readability, uses SqlParameterSource
SimpleJdbcTemplate (deprecated): Legacy wrapper, replaced by JdbcTemplate
RowMapper: Maps individual rows — reusable, no external state
ResultSetExtractor: Processes entire ResultSet (multiple rows, custom structures)
SQL scripts: Execute SQL files via ResourceDatabasePopulator for setup, testing, or migrations
PreparedStatementCallback: For full control over PreparedStatement creation and execution

Connections

Built from: JDBC — JdbcTemplate is a wrapper over raw JDBC
Built from: Spring Framework — JdbcTemplate is a Spring module for data access
Contrasts with: Spring ORM — JdbcTemplate is direct SQL; Spring ORM is object-oriented
Contrasts with: Spring Data JPA — JdbcTemplate gives SQL control; JPA abstracts SQL
Related: Hibernate Query Language — Both execute database queries; HQL is ORM-based, JdbcTemplate is SQL-based

Edge Cases & Gotchas

Large results: JdbcTemplate fetches all results into memory by default — use RowCallbackHandler or streaming for large datasets
No caching: Unlike ORM, JdbcTemplate has no built-in caching — each query hits the database
No lazy loading: All fields must be explicitly selected; no proxy-based lazy loading
SQL injection: Always use parameterized queries (? or :param), never concatenate user input into SQL strings
DataSource configuration: JdbcTemplate needs a properly configured DataSource bean; Spring Boot auto-configures one

spring-mvc-exception-handling

2026-05-13T00:00:00.000Z

The Problem

Web application errors (404, 500, validation failures, data access errors) can occur in any controller method. Without centralized handling, every method needs try-catch blocks, error view selection, and status code mapping — leading to duplicated error-handling code and inconsistent error responses.

Core Idea

Spring MVC provides a layered exception handling architecture: @ExceptionHandler on controllers handles controller-specific exceptions, @ControllerAdvice provides global exception handling across all controllers, and HandlerExceptionResolver is the lowest-level SPI for complete customization.

How It Works

Controller-level: @ExceptionHandler(SomeException.class) methods in the same controller catch specific exceptions
Global-level: @ControllerAdvice classes contain @ExceptionHandler methods that apply to all controllers
Resolution order: Controller-level → ControllerAdvice → HandlerExceptionResolver chain
Error views: Exception handler returns ModelAndView with error details and status codes
REST errors: @RestControllerAdvice returns error JSON instead of error views
ResponseEntity: ExceptionHandler methods can return ResponseEntity<ErrorResponse> for full HTTP response control

Visual Explanation

Key Properties

@ExceptionHandler: Method-level annotation for handling specific exception types within a controller
@ControllerAdvice: Global exception handling across all controllers; also adds model attributes globally
@RestControllerAdvice: @ControllerAdvice + @ResponseBody, for REST APIs returning JSON error responses
HandlerExceptionResolver: Interface for custom exception resolution logic; lowest level
Status codes: @ResponseStatus(HttpStatus.NOT_FOUND) sets HTTP status on exceptions
ErrorAttributes: Spring Boot provides default error attributes (timestamp, status, error, message, path)

Connections

Built from: Spring MVC — Exception handling is integral to Spring MVC’s request processing
Built from: Spring Controller — @ExceptionHandler methods live in controllers or @ControllerAdvice
Related: Spring Form Handling — Validation errors (BindingResult) versus exception handling
Contrasts with: Try-Catch-Finally — Java try-catch is imperative; Spring MVC exception handling is declarative and cross-cutting

Edge Cases & Gotchas

HandlerExceptionResolver vs @ExceptionHandler: @ExceptionHandler cannot control response status for unhandled exceptions; HandlerExceptionResolver can
Async exceptions: Exceptions in @Async methods or DeferredResult need separate handling (AsyncExceptionHandler)
ResponseStatusException: Spring 5+ provides ResponseStatusException for programmatic status + reason without custom exception classes
Security exceptions: Spring Security exceptions are handled by the Security filter chain, not ControllerAdvice

spring-mvc

2026-05-13T00:00:00.000Z

The Problem

Building web applications requires handling HTTP requests, mapping URLs to handlers, parsing parameters, validating input, rendering views, and managing sessions. Without a structured framework, web-tier code becomes a messy mix of request handling, business logic, and presentation.

Core Idea

Spring MVC is a web framework built on the Model-View-Controller pattern, with the DispatcherServlet as the front controller. It cleanly separates concerns: Controllers handle requests, Models hold data, and Views render output. The framework handles request routing, parameter binding, validation, and view resolution transparently.

How It Works

DispatcherServlet: The front controller receives all HTTP requests and delegates to configured components
Handler mapping: DispatcherServlet consults HandlerMapping to find which controller method handles the request URL
Controller execution: The selected @Controller method executes, processes the request, and returns a ModelAndView
View resolution: ViewResolver maps logical view names (e.g., “home”) to actual view templates (home.jsp, home.html)
Response rendering: View renders the model data into HTML, JSON, or XML

Visual Explanation

Key Properties

Front controller pattern: DispatcherServlet centralizes request handling
Annotation-based: @Controller, @RequestMapping, @RequestParam, @ModelAttribute
View technology agnostic: Works with JSP, Thymeleaf, FreeMarker, Mustache
REST support: @RestController combines @Controller + @ResponseBody for JSON/XML APIs
Data binding: Automatically binds request parameters to Java objects
Validation: @Valid + BindingResult for declarative input validation

Connections

Built from: Spring Framework — Spring MVC is built on Spring Core (IoC, DI)
Built from: DispatcherServlet — The front controller is the entry point of Spring MVC
Related: Spring Controller — @Controller methods handle specific request mappings
Builds into: Spring Boot — Spring Boot auto-configures Spring MVC with embedded Tomcat
Related: Spring Form Handling — Form handling and validation in Spring MVC
Contrasts with: JSP — JSP is a view technology; Spring MVC is a full web framework

Edge Cases & Gotchas

Hidden HttpMethod: HTML forms only support GET/POST; Spring’s HiddenHttpMethodFilter converts _method=PUT to actual PUT
@ModelAttribute vs @RequestParam: @ModelAttribute binds complex objects; @RequestParam binds single parameters
ViewResolver chaining: Multiple ViewResolvers with order priority — first match wins
async requests: DeferredResult and Callable for long-lived async processing in controllers

spring-orm

2026-05-13T00:00:00.000Z

The Problem

Using Hibernate directly requires manually managing SessionFactory, Sessions, and transactions. Each operation needs opening a session, beginning a transaction, performing the operation, committing or rolling back, and closing the session. This boilerplate leads to resource leaks and inconsistent transaction boundaries.

Core Idea

Spring ORM provides a consistent integration layer between Spring and ORM frameworks (Hibernate, JPA, MyBatis). It centralizes SessionFactory creation, provides automatic session management via HibernateTemplate, integrates with Spring’s transaction management, and translates Hibernate exceptions into Spring’s DataAccessException hierarchy.

How It Works

LocalSessionFactoryBean: Spring creates a Hibernate SessionFactory as a Spring bean, configuring it via Spring’s property management
HibernateTransactionManager: Connects Hibernate’s transaction API to Spring’s platform transaction management — enables @Transactional on Hibernate operations
Session management: Spring opens and closes Hibernate Sessions automatically per operation (OpenSessionInView pattern)
Exception translation: @Repository + PersistenceExceptionTranslationPostProcessor translates Hibernate exceptions to Spring’s DataAccessException
Automatic table creation: Hibernate’s hibernate.hbm2ddl.auto property (create, update, validate) automatically generates DDL from entity mappings

Visual Explanation

Key Properties

Centralized config: Hibernate properties (dialect, DDL auto, connection pool) configured in Spring, not hibernate.cfg.xml
Automatic session: No session.open()/close() needed — Spring manages the lifecycle
Transaction integration: Standard @Transactional works with Hibernate operations
Exception translation: Vendor-specific exceptions → Spring’s unified DataAccessException hierarchy
Automatic DDL: hibernate.hbm2ddl.auto generates database tables from entity classes
Lazy loading support: OpenSessionInViewFilter keeps session open during view rendering (controversial)

Connections

Built from: Spring Framework — Spring ORM is a Spring module for ORM integration
Built from: Hibernate ORM Framework — Spring ORM integrates Hibernate as the ORM provider
Builds into: Spring Data JPA — Spring Data JPA uses Spring ORM under the hood for Hibernate integration
Related: Spring JDBC Template — Both Spring ORM and JDBC Template are data access approaches in Spring
Contrasts with: Container-Managed Persistence — CMP is EJB’s ORM; Spring ORM is more flexible and standalone

Edge Cases & Gotchas

OpenSessionInView anti-pattern: Keeping the session open during view rendering encourages lazy loading outside transactional boundaries, leading to N+1 queries hidden in views
SessionFactory per data source: Multiple databases require separate SessionFactory beans
Hibernate version conflicts: Spring Boot manages Hibernate version; manual dependency management can cause incompatibilities
DDL auto in production: Never use hibernate.hbm2ddl.auto=create or update in production — use validate or Flyway/Liquibase

spring-security-authentication

2026-05-13T00:00:00.000Z

The Problem

Applications need to verify user identities and control access based on roles. Hard-coded authentication logic is inflexible, insecure, and doesn’t integrate with standard identity providers. Developers need a pluggable authentication system that supports multiple strategies.

Core Idea

Spring Security Authentication verifies user identity via configurable AuthenticationProvider implementations. The UserDetailsService interface loads user data (username, password hash, roles) from any backend. Role-based authorization restricts access to specific endpoints or methods based on granted authorities.

How It Works

Authentication request: User submits credentials (username/password, token, certificate)
AuthenticationProvider chain: Each provider checks if it can handle the authentication type — first match wins
UserDetailsService: Loads user from database: loadUserByUsername(String username) → UserDetails
Password verification: PasswordEncoder.matches(rawPassword, encodedPassword) — should be BCrypt, not plain text
GrantedAuthority: User roles returned as GrantedAuthority objects (prefix ROLE_ for role-checking)
SecurityContextHolder: SecurityContextHolder.getContext().setAuthentication(auth) — stored in ThreadLocal
Role-based access: @PreAuthorize("hasRole('ADMIN')") or hasAuthority('WRITE_PRIVILEGE')

Visual Explanation

digraph auth_flow {
  rankdir=TB
  node [shape=box style=filled fillcolor="#f0f4ff" fontname="Helvetica" fontsize=12]
  edge [fontname="Helvetica" fontsize=10]
 
  LOGIN [label="User submits\username/password"]
  FILTER [label="Authentication Filter\n(e.g., UsernamePasswordAuthFilter)"]
  PROVIDER [label="AuthenticationProvider\n(chain of providers)" fillcolor="#ffe5cc]
  UDS [label="UserDetailsService\n(load from DB)"]
  ENC [label="PasswordEncoder\n(BCrypt match)"]
  CTX [label="SecurityContextHolder\n(ThreadLocal)"]
  ROLE [label="Role Check\n@PreAuthorize\n(hasRole('ADMIN'))"]
  ACCESS [label="Access\nGranted / Denied"]
 
  LOGIN -> FILTER
  FILTER -> PROVIDER
  PROVIDER -> UDS
  UDS -> ENC
  ENC -> PROVIDER
  PROVIDER -> CTX [label="store auth"]
  CTX -> ROLE
  ROLE -> ACCESS
}

Key Properties

Multiple providers: DAO, LDAP, OAuth2, remember-me, JWT — configured as a provider chain
UserDetailsService: Core interface for loading users from any data source (JDBC, JPA, Mongo)
PasswordEncoder: Never store plain-text passwords; BCrypt, SCrypt, Argon2 recommended
Role hierarchy: ROLE_ADMIN > ROLE_USER — admin inherits user permissions
Remember-me: Persistent token-based authentication across browser sessions
Pre-authentication: For environments where authentication happens upstream (e.g., SSO, X.509 certs)

Connections

Built from: Spring Security — Authentication is a core component of Spring Security
Related: Spring Security CSRF and JWT — JWT is an alternative authentication mechanism
Related: JAAS — JAAS is Java’s standard auth; Spring Security abstracts and improves it
Contrasts with: Session Authentication — Session auth stores state on server; JWT is self-contained
Builds into: JWT Authentication — JWT can be used as a Spring Security authentication provider

Edge Cases & Gotchas

PasswordEncoder upgrade: Migrating from MD5/SHA to BCrypt requires supporting both encoders simultaneously during transition
UserDetailsService caching: Without caching, every request to check auth triggers a database load; use caching layer
ROLE_ prefix: hasRole('ADMIN') automatically checks for ROLE_ADMIN; hasAuthority('ADMIN') checks for exact string
ThreadLocal cleanup: SecurityContextHolder is ThreadLocal — in async processing, the context doesn’t propagate automatically
Blank passwords: PasswordEncoder should throw exception for blank/null passwords, not silently accept

spring-security-csrf-jwt

2026-05-13T00:00:00.000Z

The Problem

Web applications face two critical security challenges: Cross-Site Request Forgery (CSRF) tricks authenticated users into performing unintended actions, and Cross-Origin Resource Sharing (CORS) policies prevent legitimate cross-domain requests. Additionally, stateless authentication (JWT) needs careful implementation to avoid token theft and replay attacks.

Core Idea

Spring Security provides built-in CSRF protection (synchronizer token pattern, enabled by default for state-changing requests) and CORS configuration (allowing specified origins, methods, and headers). For JWT authentication, Spring Security integrates with BearerTokenAuthenticationFilter to validate signed tokens on every request without server-side session state.

How It Works

CSRF protection: Server generates a unique token, embedded in forms or sent via header. State-changing requests (POST/PUT/DELETE) must include this token. The CsrfFilter validates it against the stored token
CORS: CorsFilter checks Origin header against allowed origins. Spring Security configures via .cors() and @CrossOrigin on controllers
JWT authentication: Client sends JWT in Authorization: Bearer <token> header. BearerTokenAuthenticationFilter extracts and validates token signature and claims
JWT validation: Verify signature (HMAC or RSA), check expiration (exp claim), verify issuer (iss) and audience (aud)
Stateless sessions: SessionCreationPolicy.STATELESS — no HTTP session, every request fully authenticated

Visual Explanation

Key Properties

CSRF default: Enabled by default for web apps; disabled automatically for REST APIs (stateless)
CORS configuration: Allowed origins, methods, headers, credentials, and max age via CorsConfigurationSource
@CrossOrigin: Per-controller CORS configuration for specific endpoints
JWT Bearer tokens: spring-boot-starter-oauth2-resource-server for JWT validation
Token validation: Signature, expiration (exp), not-before (nbf), issuer (iss), audience (aud)
Stateless architecture: JWT enables stateless auth — no server-side session, scales horizontally

Connections

Built from: Spring Security — CSRF, CORS, and JWT are Spring Security modules
Built from: Spring Security Authentication — JWT provides bearer token authentication
Related: JWT Authentication — The JWT token concept; Spring Security implements JWT validation
Related: CORS — CORS is an HTTP mechanism; Spring Security configures it
Contrasts with: JAAS — JAAS is container-managed; Spring Security JWT is application-managed and stateless

Edge Cases & Gotchas

CSRF with REST APIs: If using stateless sessions (JWT), disable CSRF — there’s no session to protect
CSRF with file upload: Multipart requests need CSRF token in URL parameter or separate header
JWT revocation: JWT tokens can’t be revoked before expiration (no server-side state) — use short expirations + refresh tokens
CORS vs CSRF: CORS is about cross-origin access; CSRF is about request forgery — they address different threats
Bearer token storage: Storing JWT in localStorage is vulnerable to XSS; httpOnly cookies are safer but require CSRF protection
JWT size: Large JWT tokens with many claims can exceed header size limits — keep claims minimal

spring-security

2026-05-13T00:00:00.000Z

The Problem

Securing enterprise applications requires implementing authentication (who are you?), authorization (what can you do?), and protection against common attacks (CSRF, session fixation, clickjacking). Doing this correctly is hard — rolling custom security is error-prone and leads to vulnerabilities.

Core Idea

Spring Security is a comprehensive security framework for Java applications providing authentication, authorization, and protection against common exploits. It uses a filter chain architecture that intercepts every HTTP request, applies configured security rules, and integrates with various authentication providers (database, LDAP, OAuth2, JWT).

How It Works

Security filter chain: A chain of servlet filters processes every request. Key filters: UsernamePasswordAuthenticationFilter (form login), BasicAuthenticationFilter (HTTP Basic), FilterSecurityInterceptor (authorization)
Authentication: User credentials → AuthenticationProvider validates → SecurityContextHolder stores the Authentication object for the request
Authorization: @PreAuthorize("hasRole('ADMIN')") or AccessDecisionManager checks if the authenticated user has the required authority
CSRF protection: Synchronizer token pattern — generated token embedded in forms, validated on state-changing requests
Security annotations: @Secured, @PreAuthorize, @PostAuthorize, @PreFilter, @PostFilter
UserDetailsService: Interface for loading user-specific data (typically from a database)

Visual Explanation

Key Properties

Filter chain: Modular, ordered chain of security filters, each handling one concern
Authentication providers: DAO (database), LDAP, OAuth2, JWT, remember-me, custom
Authorization methods: URL-based (.antMatchers().hasRole()), method-based (@PreAuthorize)
CSRF protection: Enabled by default for state-changing POST/PUT/DELETE requests
Security headers: Default headers for XSS, content-type sniffing, clickjacking, HSTS
Password encoding: PasswordEncoder interface with BCrypt, SCrypt, Argon2 implementations
JSP tag library: <sec:authorize access="hasRole('ADMIN')"> for view-level security

Connections

Built from: Spring Framework — Spring Security builds on Spring AOP and DI
Related: Spring Security Authentication — Core authentication mechanisms
Related: Spring Security CSRF and JWT — CSRF protection and JWT authentication
Related: JAAS — JAAS is the standard Java auth API; Spring Security is the framework approach
Contrasts with: Session Authentication — Session auth is simpler; Spring Security provides comprehensive enterprise security

Edge Cases & Gotchas

Filter order: Security filters must come before Spring MVC’s DispatcherServlet in the filter chain
@EnableWebSecurity vs XML: Java config is preferred; mixing with XML can cause unexpected behavior
SecurityContext persistence: In web apps, SecurityContext is stored in the HTTP session — ensure session management is configured
Async security: @Async methods lose SecurityContext — use SecurityContextRunnable or DelegatingSecurityContextAsyncTaskExecutor
Whitelabel error page: Spring Security’s default error page appears when access is denied — customize with proper error handling

spring-spel

2026-05-13T00:00:00.000Z

The Problem

Configuration values and bean wiring often require dynamic expressions — accessing system properties, evaluating conditions, performing string operations, or calling methods. Static property files (@Value("${key}")) can only do basic key lookups; developers need runtime expression evaluation within the Spring container.

Core Idea

SpEL (Spring Expression Language) is a powerful expression language that supports querying and manipulating objects at runtime. It can be used in XML and annotation-based configurations, providing dynamic value resolution, method invocation, collection manipulation, and boolean evaluation.

How It Works

Syntax: Expressions start with #{ and end with } — e.g., #{systemProperties['user.dir']}
Property access: #{beanName.property} accesses any Spring bean’s property
Method invocation: #{beanName.method(args)} calls methods on beans
Operators: Arithmetic (+, -, *, /), relational (==, lt, gt), logical (and, or, not)
Collection selection: #{users.?[age > 25]} filters collections; .^ first match, .$ last match
Collection projection: #{users.![name]} extracts specific property from each element
Safe navigation: #{bean?.property} — returns null if bean is null instead of NPE
Ternary: #{bean.score > 50 ? 'Pass' : 'Fail'}

Visual Explanation

Key Properties

Dynamic evaluation: Expressions are evaluated at runtime, not compile time
Bean access: Directly reference Spring beans by name (#{myBean.count})
Null-safe: ?. operator prevents NullPointerException in navigation chains
Collection operators: Selection (?[]), projection (![]), sorting according to a property
Type operators: T(java.lang.Math).PI references static types and methods
Integration: Works with @Value, XML <property>, security annotations, and more

Connections

Built from: Spring Framework — SpEL is a Spring Core module
Built from: Spring IoC Container — SpEL evaluates within the container’s context
Related: Spring Annotations — @Value with SpEL provides dynamic property injection
Contrasts with: EJB Query Language (EJB-QL) — EJB-QL queries entities; SpEL queries beans and system properties
Related: Java Operators — SpEL operators extend Java’s with collection-safe operations

Edge Cases & Gotchas

Syntax confusion: #{} (SpEL evaluation) vs ${} (property placeholder) — they can be nested: #{${property}}
Performance: Complex SpEL expressions are evaluated on every access — avoid in hot paths
Method invocation: Only public methods on beans can be called; private/static methods require T() type operator
Security: SpEL can call any bean method and access any property — never use user-provided input in SpEL expressions (security risk)

test-driven-development

2026-05-13T00:00:00.000Z

The Problem

Writing code without tests leads to bugs that are found late, regression failures when refactoring, and code that’s hard to change with confidence. Testing after coding often gets skipped due to deadlines. Developers need a discipline that ensures code is tested from the start.

Core Idea

Test-Driven Development (TDD) is a software development practice where tests are written before the implementation code. The cycle is: Red (write a failing test) → Green (write the minimal code to pass) → Refactor (improve code while tests stay green). This ensures 100% test coverage of specified behavior and drives clean, testable design.

How It Works

Red: Write a test for the NEXT piece of functionality. Run it — it should fail (red) because the code doesn’t exist yet
Green: Write the SIMPLEST possible implementation code to make the test pass. Don’t optimize, don’t over-engineer
Refactor: With tests passing (green), improve the code: remove duplication, extract methods, rename variables. Tests ensure refactoring doesn’t break anything
Repeat: Add the next test, see it fail, implement, refactor. Each cycle is 30-60 seconds
JUnit + Mockito: JUnit provides the test framework; Mockito isolates the unit under test by mocking its dependencies (services, repositories)

Visual Explanation

digraph tdd_cycle {
  rankdir=LR
  node [shape=box style=filled fillcolor="#f0f4ff" fontname="Helvetica" fontsize=12]
  edge [fontname="Helvetica" fontsize=10]
 
  RED [label="RED\nWrite failing test\n(test doesn't compile\nor assertion fails)" fillcolor="#ffe5cc]
  GREEN [label="GREEN\nWrite minimal code\n(make test pass)" fillcolor="#d4edda]
  REFACTOR [label="REFACTOR\nImprove code\n(duplication, naming,\nstructure)" fillcolor="#cce5ff]
  NEXT [label="Next Test"]
 
  RED -> GREEN [label="1. implement"]
  GREEN -> REFACTOR [label="2. all green"]
  REFACTOR -> RED [label="3. add next test"]
  REFACTOR -> NEXT [label="loop"]
}

Key Properties

Test-first: Tests are written before implementation, not after
Small cycles: Red-Green-Refactor in 30-60 second iterations
Minimal implementation: Write just enough code to pass the test — no more
Continuous refactoring: Improve code quality with the safety net of passing tests
Design driver: TDD naturally drives decoupled, testable designs (dependency injection, interfaces)
Mockito integration: @Mock for dependencies, @InjectMocks for the system under test
Test coverage: Every line of production code exists because a test required it

Connections

Built from: JUnit Testing — JUnit is the testing framework used in TDD
Built from: JUnit Annotations and Lifecycle — Lifecycle hooks structure TDD test fixtures
Related: JUnit Parameterized Tests — Parameterized tests express TDD edge case coverage
Related: Java Methods — TDD drives clean method design with single responsibilities

Edge Cases & Gotchas

TDD is a discipline, not a tool: It takes practice to write tests first consistently — especially when under pressure
Mocking everything: Over-mocking leads to brittle tests that break when implementation details change
Testing private methods: Don’t test private methods directly — test the public API that uses them
Integration vs unit: TDD works best at the unit level; integration tests follow different patterns
Red phase must fail: If the test passes before implementation, it tests the wrong thing or duplicates an existing test

/wiki / java3

ejb-container

The Problem

Formal Definition

Explanation

How It Works

Visual Explanation

Semantic Network

Key Properties

Real-World Example

Connections

Edge Cases & Gotchas

Java3 — Map of Content

Core Concepts

Mechanisms & How Things Work

Comparisons & Tradeoffs

Suggested Reading Order

api-gateway-pattern

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

dispatcher-servlet

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

distributed-tracing

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

hibernate-annotations

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

hibernate-caching

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

hibernate-entity-mapping

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

hibernate-orm-framework

The Problem

Core Idea

How It Works

Visual Explanation

Semantic Network

Key Properties

Connections

Edge Cases & Gotchas

hql

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties