Forem: Phoenix

Proxy - Forward Proxy and Reverse Proxy

Phoenix — Wed, 22 Apr 2026 15:39:40 +0000

A proxy server is an intermediary piece of hardware/software acts like a middlemen sitting between the client and the backend server. It receives requests from clients and relays them to the origin servers.

2 types of Proxy
Forward Proxy -works for clients
Reverse Proxy works for servers

Forward Proxy
A forward proxy sits in front of clients and internet. It hides the client's identity from the server. When those clients make requests to sites and services on the internet, the proxy server intercepts those requests and then communicates with web servers on behalf of those clients, like a middleman.
Think of a VPN or corporate proxy: the server sees the proxy's IP, not yours. Use cases include privacy, content filtering, and bypassing geo-restrictions.

-> works at application level(http/https)

Advantages of a forward proxy:

Block access to certain content
it does security filtering, by stoping from downloading or opening malicious content before it reaches the server
tracks monitoring and logging of which websites visited and usage
Stores copies of frequently visited websites
Reduces internet usage and speeds things up
Provides anonymity
Access blocked content (in some cases)

VPN:
Used to securely and privately route all network traffic through an encrypted tunnel.

VPN and forward proxy serve different purposes. VPN provides secure encrypted communication, while forward proxy provides control and filtering. They are often used together in enterprise environments

Reverse Proxy

A reverse proxy sits in front of servers and internet. It hides the server's identity from the client. this proxy intercepting requests from clients. When clients send requests to the origin server of a website, those requests are intercepted by the reverse proxy server. The client thinks it is talking to one server, but the reverse proxy could be routing requests to dozens of backend servers.

_A reverse proxy is not just a load balancer, but it can perform load balancing along with other functions like caching, SSL termination, and security.
_
Advantages of a forward proxy:

Distributes traffic across multiple servers
Example:
Amazon
Netflix
Millions of users → reverse proxy spreads load
Security (very important)
Hides real server IPs
Blocks malicious traffic
Acts as first line of defense
Example:
Cloudflare sits in front of websites
Caching (performance boost)
Stores frequently requested data
Sends it quickly without hitting backend
not very data, only public/static content shared across users
reduce latency and improve performance
Example:
Homepage loads faster because proxy cached it
SSL/TLS Termination
Handles HTTPS encryption
Backend servers don’t need to handle it
Example:
NGINX manages HTTPS

1. Cloudflare (outer layer)
Sits on the internet edge
First point of contact for users worldwide
What it does:
🌍 CDN (serves content from nearest location)
🛡️ DDoS protection
🔒 SSL (HTTPS)
🚫 Blocks malicious traffic

👉 Think of it as:
Global security + performance layer

** 2. NGINX (inside your system)**
Runs on your server or infrastructure
What it does:
🔀 Routes requests to backend services
⚖️ Load balancing
🔐 SSL termination (if not handled by Cloudflare)
⚡ Caching

👉 Think of it as:
Internal traffic manager

JWT vs JWS

Phoenix — Wed, 22 Apr 2026 10:42:59 +0000

JWT (JSON Web Token) is a compact, URL-safe token format used to securely transmit information between parties as a JSON object.

Key points in definition:
Compact → small, efficient (xxxxx.yyyyy.zzzzz)
URL-safe → can be sent in headers/URLs
JSON-based → payload is JSON
Claims → contains data like userId, role
Can be signed or encrypted

JWS (JSON Web Signature) is a specification that defines how to digitally sign a payload (such as a JWT) to ensure its integrity and authenticity.

Key points:
Uses digital signature
Ensures:
Integrity (data not modified)
Authenticity (issued by trusted source)
Does not encrypt the payload

Cookies vs JWT

Phoenix — Wed, 22 Apr 2026 09:57:34 +0000

Cookies are small pieces of data stored in the browser, typically set by the server using the Set-Cookie header.

They can include attributes such as:
Max-Age / Expires → defines how long the cookie is valid
HttpOnly → prevents access from JavaScript (improves security - it cannot be accessed by JS using document.cookie XSS attacks)
Secure → ensures the cookie is only sent over HTTPS
SameSite → controls cross-site request behavior

🔁 Authentication flow using cookies (server-side sessions)

User logs in with credentials
Server: Creates a session (stored in DB/memory) Generates a session ID Sends it to the browser via:

Set-Cookie: session_id=abc123

**Browser:
**Stores the cookie
Automatically includes it in future requests:

Cookie: session_id=abc123

Because they are sent with every request (including images/scripts), large cookies can impact performance

🌐 Cookie behavior in requests
For same-origin requests → cookies are sent automatically
For cross-origin requests → must explicitly enable:
Frontend: credentials: "include" or withCredentials: true
Backend: Access-Control-Allow-Credentials: true
⏳ Expiry behavior

Session cookies (no expiry):
Deleted when browser closes
Persistent cookies (with Max-Age / Expires):
Remain after browser restart

⚠️** Important distinction**
Cookie expiry and session expiry are separate:

Cookie expiry → controlled by browser
Session expiry → controlled by server

Even if a cookie is still valid, the user is logged out if the server session has expired.

Key takeaway
Cookie = identifier stored in browser
Session = actual user data stored on server
Cookie is automatically sent with requests (with some cross-origin rules

Challenges
In a distributed system with multiple backend servers behind a load balancer, session-based authentication can be harder to scale because sessions are stored on the server side and creates challenges like session sharing, synchronization, and additional database or cache lookups on every request

If a session is stored on one server and a subsequent request is routed to a different server, that server won’t recognize the session, making the user appear logged out.

To solve this, systems typically use a shared session store like Redis or a database that all servers can access. However, this introduces additional overhead because every request requires a lookup to fetch session data, which adds latency and increases infrastructure complexity.

This is why session-based systems are considered stateful and harder to scale compared to stateless approaches like JWT.

CSRF = Cross-Site Request Forgery

👉 It’s an attack where:

A malicious website tricks your browser into making a request to another site where you are already logged in.

CSRF is an attack where a malicious site tricks a user’s browser into making unintended requests to another site where the user is authenticated. It happens because cookies are automatically sent with requests. CSRF tokens prevent this by adding a secret value that must be validated by the server.

Browsers automatically send cookies with requests

That’s the root cause.

JWT

JWT (JSON Web Token) is a self-contained token that carries user information and proves authentication.

it is compact URL-safe means of representing claims to be transferred between two parties”. A JWT leverages Javascript Object Notation (JSON) to represent these claims, resulting in a small and simple token that is used by protocols such as OpenID Connect 1.0 to represent identity to the application and OAuth 2.0 to represent an access token for API authorization.

Structure:

header.payload.signature

Header → algorithm (e.g., HS256)
Payload → user data (userId, role, exp)
Signature → ensures integrity (not tampered)

🔐 Signing (Data Integrity)
Server signs the token using a secret key
Signature ensures

Token is issued by server
Data is not modified

👉 If payload changes → signature becomes invalid

⚠️ JWT is NOT encrypted by default
Payload is base64 encoded (readable)
Anyone can decode it
But cannot modify it (signature protects it)

👉 Do NOT store sensitive data in JWT

🔁 JWT Authentication Flow

User logs in
Server generates JWT
Client stores token
Client sends token in requests:

Authorization: Bearer <token>

Server verifies signature → authenticates user
📦 Where to store JWT

localStorage ✅ Pros:

Easy to use
Full control in frontend ❌ Cons:
Vulnerable to XSS attacks (JS can read token)
Cookies (HttpOnly) ✅ Pros:
Protected from XSS (HttpOnly)
Automatically sent with requests ❌ Cons:
Vulnerable to CSRF attacks

Storage Risk
localStorage XSS
Cookies CSRF

✅ Best practice
Store JWT in HttpOnly cookies
Use:
Secure
SameSite

🚨 CSRF (Cross-Site Request Forgery)
🧾 Example
You are logged into bank.com

Attacker site triggers:

<img src="https://bank.com/transfer?amount=1000">

Browser sends:

Cookie: session_id=abc123

👉 Server thinks request is valid

🛡️** CSRF Protection**

CSRF Token (core idea)

👉 Add a secret token that attacker cannot access

🔁 Synchronizer Token Pattern

Server stores
session → csrf_token
Sends token to client
Client sends it back
Server validates

🔁 Double Submit Cookie Patter
Step 1: Server sends cookies
session_id=abc123 (HttpOnly)
csrf_token=xyz789 (readable by JS)
Step 2: Client sends request
Cookie: session_id=abc123; csrf_token=xyz789
Header: X-CSRF-Token: xyz789
Step 3: Server validates
cookie csrf_token === header csrf_token
✅ Why it works
Attacker cannot:
Read cookie
Set custom headers

👉 Request is rejected

SameSite Cookies Set-Cookie: session_id=abc123; SameSite=Strict

👉 Prevents cookies in cross-site requests

🔐 Access Token vs Refresh Token
🧾 Access Token
Short-lived (e.g., 15 min)
Used for API requests
Authorization: Bearer
🔁 Refresh Token
Long-lived (e.g., 7 days)
Used to get new access tokens

⚠️ Important Concepts Summary
Integrity vs Confidentiality
Integrity → data not modified (JWT provides this)
Confidentiality → data hidden (JWT does NOT provide by default)
Sessions vs JWT
Session → server stores data (stateful)
JWT → client carries data (stateless)
CSRF vs XSS
Attack Target
CSRF Cookies (auto-sent)
XSS localStorage / JS-accessible data

SAML - Single Sgn On

Phoenix — Tue, 21 Apr 2026 18:14:36 +0000

*How SAML works *
SAML (Security Assertion Markup Language) is an XML-based protocol for Single Sign-On. The core idea: instead of every app managing its own login, one trusted system (the IdP) handles authentication and vouches for you to other apps (SPs) via a signed XML token.
There are two flows — SP-initiated (most common — user hits the app first) and IdP-initiated (user starts from an IdP portal). The diagram below shows SP-initiated.

Core actors

SP (Service Provider) — the app the user wants to access. It trusts the IdP but cannot authenticate users itself.
IdP (Identity Provider) — the central auth system (Okta, Azure AD, Google Workspace). It knows who the user is.
Principal — the end user being authenticated.

Key messages

AuthnRequest — XML request from SP to IdP saying "please authenticate this user." Contains an AssertionConsumerServiceURL (where to send the response back).
SAMLResponse — XML sent back from IdP to SP, containing one or more Assertions.
Assertion — the actual claim inside the response. Three types:

Authentication assertion — "this user logged in at time X"
Attribute assertion — "this user's email is x@y.com, role is admin"
Authorization assertion — "this user is allowed to do Y" (rare)

Binding types (how messages travel)

HTTP Redirect binding — used for the AuthnRequest; base64-encoded and sent as a URL query parameter. Small messages only.
HTTP POST binding — used for the SAMLResponse; sent as an HTML form POST. Can carry large XML payloads.

*Security concepts
*
Signature — the IdP digitally signs the assertion using its private key. SP validates using IdP's public certificate. This is what prevents forgery.
ACS URL (Assertion Consumer Service URL) — the SP endpoint that receives the SAMLResponse. Must be registered on the IdP to prevent redirect attacks.
Entity ID — unique identifier for the SP or IdP (usually a URL). Used to look up metadata.
Metadata XML — a file exchanged between SP and IdP during setup containing certificates, URLs, and supported bindings.
Relay State — an opaque value that carries where the user originally wanted to go, so SP can redirect them there after login.
NotBefore / NotOnOrAfter — time constraints on the assertion to prevent replay attacks.

Spring AOP

Phoenix — Mon, 06 Apr 2026 09:03:30 +0000

In Spring AOP, a join point represents a point in program execution where an aspect can be applied, typically a method execution.
A pointcut is an expression that selects specific join points where we want to apply additional behavior(advice).
An advice defines what action should be executed at those selected join points, such as before or after a method call.
An aspect is a combination of pointcut and advice, representing a complete cross-cutting concern like logging or transaction management.

Spring implements AOP using proxy objects, which intercept method calls and apply the defined advice at runtime.

When a Spring application starts, it scans for beans and also detects classes annotated with @aspect.
These aspect classes contain pointcut expressions, which define where the advice should be applied.
Spring then matches these pointcuts against eligible methods in target beans (which are the join points in Spring AOP).
If a match is found, Spring registers this AOP configuration and creates a proxy around the target bean so that the advice can be applied at runtime.

When a method is invoked on the proxied bean, the call is intercepted by the proxy.
The proxy checks if the method matches any pointcut expressions, and if so, executes the corresponding advice.
After applying the advice, the proxy delegates the call to the actual method in the target object.

Application Startup:

Scan beans
Detect @aspect classes
Read pointcuts and advice
Match pointcuts with target bean methods
Create proxy for matching beans

Runtime:

Method call → goes to proxy
Proxy intercepts
Executes advice
Calls actual method

How does AOP work using @aspect in Spring?

In Spring AOP, when we define a class with @aspect, Spring treats it as a container for cross-cutting concerns.
During application startup, Spring scans these aspects and creates proxy objects for the target beans.
When a method is invoked on the target bean, the call goes through the proxy instead of directly to the object.
The proxy intercepts the method call, checks if any pointcut expressions match, and if so, executes the corresponding advice such as @Before, @After, or @Around.
After applying the advice, the proxy delegates the call to the actual target method.

This proxy-based mechanism allows Spring to add behavior like logging, transactions, or async execution without modifying the actual business logic.

For example, if I define a @Before advice on all service methods, whenever a service method is called, the proxy will first execute the logging logic and then call the actual method.

Scan → Create Proxy → Intercept → Match Pointcut → Execute Advice → Call Method

Spring AOP works by creating proxy objects that intercept method calls, apply advice based on pointcut matching, and then delegate execution to the target object.

LLM vs Agentic AI

Phoenix — Mon, 02 Mar 2026 06:57:11 +0000

LLM
An LLM (like OpenAI’s GPT models) reads text and predicts what words should come next. It can:

Answer questions
Write emails
Explain concepts
Translate languages
Help with code

But here’s the key thing:

👉 It only responds when you ask it something.
👉 It doesn’t take actions on its own.
👉 It doesn’t have goals.

ChatGPT, Claude (in basic chat mode) = LLMs in action

It’s like a very smart assistant waiting for instructions.

Agentic AI
Agentic AI is more like:
An AI that can act to achieve a goal.

Instead of just answering, it can:

Make a plan
Use tools (search the web, run code, access apps)
Make decisions without you guiding each step
Try again if something fails
Work step-by-step toward a goal

Claude Code, ChatGPT with plugins doing multi-step tasks = Agentic AI
It behaves more like an independent worker than just a chatbot.

Most agentic AI systems actually use LLMs inside them.

Think of it like this:

LLM = the brain

Agentic system = the brain + hands + memory + ability to act

Annotation in SpringBoot Web Application

Phoenix — Mon, 02 Feb 2026 07:29:45 +0000

Core Spring

@Component
Marks a class as a Spring-managed bean so it can be automatically created and injected.

@Service
Used for business logic classes; it’s a specialized form of @Component.

@Autowired
Tells Spring to automatically inject a required dependency.

@Bean
Defines a bean inside a configuration class.

@Configuration
Marks a class that contains Spring bean definitions.

@Primary
Marks a bean as the default choice when multiple beans are available.

@Qualifier
Used when multiple beans exist to specify which one should be injected.

@Repository
“Used for data access classes and also enables automatic exception translation.

@Controller
Marks a class as a web controller that handles HTTP requests.

@RestController
A controller that returns data (usually JSON) instead of views.

Spring Boot
@SpringBootApplication
Main annotation that enables auto-configuration, component scanning, and configuration support.

@EnableAutoConfiguration
Allows Spring Boot to automatically configure beans based on the project setup.

@ComponentScan
Tells Spring where to look for components.

@Value
Used to read values from application.properties.

Password Management - SpringBoot

Phoenix — Mon, 02 Feb 2026 06:12:39 +0000

Why Password Hashing Is Needed

Storing passwords in plain text is dangerous.
If a database is leaked, attackers immediately get all user passwords.

So instead of storing passwords, we store hashed values.

A hash is a one-way mathematical function that converts a password into an unreadable string.
You cannot reverse it to get the original password.

mypassword → $2a$10$Hf7sd8KJH...3fd2

How Login Works with Hashed Passwords

When a user logs in:
User enters password
Spring Security hashes the entered password
It compares the new hash with the stored hash in DB
If both match → login succeeds
The original password is never stored or compared

PasswordEncoder in Spring Security

Spring Security uses an interface called:

PasswordEncoder

It has two main methods:

String encode(CharSequence rawPassword);
boolean matches(CharSequence rawPassword, String encodedPassword);

Best Algorithm: BCrypt

Spring recommends BCrypt because it:

Uses salt automatically
Is slow (harder for hackers to brute force)
Is adaptive (can be made stronger over time)

@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();
}

Why Salting Matters

Without salt:

password → hash

With salt:

password + randomValue → hash

Even if two users have the same password, their hashes will be different.

BCrypt handles salting automatically.

“A salt is a random value added to a password before hashing to make each hash unique and protect against rainbow-table and brute-force attacks.”

How Salt Works

User creates a password
System generates a random salt
Password + salt are hashed together
Both salt and hash are stored in the database

Example:

$2a$10$WERTY...SALT...HASH

When user logs in:

Spring Security extracts the salt from the stored hash
It hashes the entered password using that same salt
If hashes match → login succeeds

Tomcat Server - Servlet Container

Phoenix — Sat, 31 Jan 2026 09:48:55 +0000

Tomcat is the web server that runs your Spring application and connects it to the browser.

What is a Servlet?

In Java web development, a Servlet is just a Java class that:

Receives an HTTP request and returns an HTTP response

Like this:

Browser  →  Servlet  →  Response (HTML / JSON)

Example:

GET /login

Servlet runs Java code and returns:

<h1>Welcome</h1>

But…

A servlet cannot run by itself
It needs a Servlet Container

What is a Servlet Container?

A Servlet Container is a software that:

✔ Starts your servlets
✔ Listens to HTTP requests
✔ Calls the right servlet
✔ Sends the response back
✔ Manages threads, memory, security

Servlet Container = Runtime environment for servlets

So we need something that:

Opens port 8080
Accepts browser requests
Runs your servlet Java code

That “something” is called a Servlet Container

What is Tomcat?
Apache Tomcat is a Servlet Container

Tomcat’s job is:

Browser → Tomcat → Servlet → Response → Tomcat → Browser

Tomcat:

Opens a port (like 8080)
Understands HTTP
Runs servlets
Manages lifecycle of web apps

Without Tomcat, your Spring web app is just Java files — nobody can access it via browser.

Spring is a framework that helps you write Java code.

So Spring needs Tomcat to run on.

Think like this:

Spring Boot Application
    ↓
Runs inside Tomcat
    ↓
Tomcat runs inside JVM

What happens when you run a Spring Boot app?

When you click Run on:

@SpringBootApplication
public class MyApp {
    public static void main(String[] args) {
        SpringApplication.run(MyApp.class, args);
    }
}

Spring Boot:

Starts Tomcat internally
Registers Spring as a servlet
Tomcat listens on port 8080
Requests come in
Tomcat forwards them to Spring
Spring runs your controllers

When you create a Spring Boot Web project, this dependency is added automatically:

spring-boot-starter-web

Inside it is:

spring-boot-starter-tomcat

Spring Boot comes with Tomcat built-in by default

Spring Boot creates exactly ONE main servlet

It is called:

DispatcherServlet

This is Spring’s front controller.

What is DispatcherServlet?

It is a special servlet written by Spring.

Tomcat talks only to servlets.
So Spring creates one servlet and tells Tomcat:

“Send all requests to this servlet.”

So flow becomes:

Browser
   ↓
Tomcat
   ↓
DispatcherServlet (Spring)
   ↓
Your @Controller / @RestController

One DispatcherServlet
        |
        |-- "/login" → login()
        |-- "/register" → register()
        |-- "/products" → products()

So:

Spring has one servlet but thousands of routes

What happens internally when you hit a URL in Spring Boot?

You type this in browser

http://localhost:8080/hello

1️⃣ Browser sends HTTP request

Browser sends:

GET /hello
Host: localhost:8080

This goes to…

2️⃣ Tomcat (Web Server)
Tomcat is running because Spring Boot started it.

Tomcat:

Is listening on port 8080
Receives the HTTP request
But Tomcat doesn’t know Spring controllers.

It only knows:

“I must send requests to a servlet”

Spring registered one servlet:

DispatcherServlet

So Tomcat forwards request to it.

3️⃣DispatcherServlet (Heart of Spring MVC)

DispatcherServlet receives:

GET /hello

4️⃣ HandlerMapping

Spring looks in HandlerMapping
This is just an internal routing table.

It finds:

/hello → HelloController.hello()

5️⃣ Spring calls your method

Your controller runs:

Now it asks:

“Which controller method should handle /hello?”

To answer that, Spring has built a map when app started:

/hello  →  hello()
/login  →  login()
/users  →  getUsers()

Annotation Returns
@Controller HTML page
@RestController JSON / Text / Data

@RestController = @Controller + @ResponseBody

Beans using Autowiring

Phoenix — Thu, 29 Jan 2026 15:49:32 +0000

Creating beans alone is not enough.
They must also be wired together.

That wiring is what Autowiring (DI) does.

What does “wiring” mean?

Connecting beans together by injecting one bean into another.

Car → needs → Engine

@Autowired
Engine engine;

Spring injects the dependency for you.

That is autowiring.

What is @Autowired?

@Autowired tells Spring to automatically inject a required dependency into a Spring Bean.

It is Spring’s way of doing Dependency Injection

When @Autowired is on a setter

@Component
class Car {

    private Engine engine;

    @Autowired
    public void setEngine(Engine engine) {
        this.engine = engine;
    }
}

You might wonder:

“Who calls this setter? I never call it.”

Spring does.

What happens internally?

When Spring starts:

Spring creates the Car object using its constructor
Spring looks for any @Autowired methods
It finds setEngine(...)
It looks for an Engine bean
It finds it in the context
It calls the setter
car.setEngine(engineBean);

The dependency is injected

This happens automatically during bean creation.

Beans define which objects Spring manages, and autowiring defines how those objects are connected to each other through dependency injection.

Creating Spring Beans

Phoenix — Thu, 29 Jan 2026 09:42:15 +0000

When you use Spring without Spring Boot, you start by creating something called the ApplicationContext.
This object is the Spring IoC container — it is the place where Spring keeps and manages all the objects it creates.

ApplicationContext context =
        new AnnotationConfigApplicationContext(AppConfig.class);

Here, you are telling Spring:

“Start your container and use AppConfig as the configuration.”

What is AppConfig?

AppConfig is a class you write and mark with @Configuration:

@Configuration
public class AppConfig {
}

This tells Spring:

This class contains methods that create objects Spring should manage (factory of Spring Beans)

Inside this class, you write methods marked with @Bean :

@Configuration
public class AppConfig {

    @Bean
    public Engine engine() {
        return new Engine();
    }

    @Bean
    public Car car() {
        return new Car(engine());
    }
}

Each @bean method:

The object returned by this method should be stored in the Spring context as a Bean.
And hands it over to Spring

Spring then takes that object and stores it inside the ApplicationContext.

These stored objects are called Spring Beans.

What happens when the context is created?

When this line runs:

new AnnotationConfigApplicationContext(AppConfig.class);

Spring does the following:

Reads AppConfig
Finds all methods marked with @bean
Calls those methods
Creates the objects (Engine, Car)
Stores them inside the context
Keeps track of their dependencies and lifecycle

Now the IoC container fully controls these objects.

How do you use them?

Instead of writing:

Car car = new Car();

Car car = context.getBean(Car.class);

Spring gives you the object it created and manages.

That is Inversion of Control:
Spring controls object creation, not you.

Putting it all together

@Configuration tells Spring where the bean definitions are
@Bean tells Spring which objects to create
AnnotationConfigApplicationContext starts the IoC container
ApplicationContext stores and manages the beans
You ask the context for objects instead of using new

@Component is one of the most important Spring annotations — it’s how you tell Spring:

“Please create and manage an object of this class.”

What is @Component?

@Component marks a class as a Spring Bean so that Spring will automatically create and manage its object in the IoC container.

@Component
public class Engine {
}

This tells Spring:

“When the context starts, create an Engine object and store it.”

How Spring finds it

When the ApplicationContext starts, Spring performs component scanning.

It looks through your packages and finds classes annotated with:

@Component
@Service
@Repository
@Controller These are all forms of @Component.

Spring Beans, Context, Spring IoC container

Phoenix — Thu, 29 Jan 2026 07:16:10 +0000

Spring Beans
we hear a lot about beans when we are working with spring

A Spring Bean is any Java object that is instantiated, configured, and managed by the Spring IoC container.

a Bean is a POJO(Plain Old Java Object)
But not every POJO is a Bean.

A Bean = POJO + managed by Spring

What does “managed by Spring” mean?
Spring:

Creates the object
Stores it in the container
Injects its dependencies
Controls its lifecycle
Destroys it when the app shuts down
Only such objects are called Beans.

It is not mandatory that every class inside your application should be beans, like (utilities classes)

How spring knows which needs to be maintained?

with the help of configurations that we supply either through XML files or Annotations

Context
context is like a memory location where we add all the object instances that we want the framework to manage. by default spring doesn't know any of the objects that we define in the application. to enable spring to see your object you need to add them to the context.

We add classes to the Spring context by annotating them so that Spring can create and manage their objects as beans.

*Spring IoC container *
The Spring IoC Container is the core part of Spring that creates, manages, and injects application objects (beans) and controls their lifecycle.

Here’s the big picture

When a Spring (or Spring Boot) application starts, the first thing it creates is something called the ApplicationContext.
This ApplicationContext is the Spring IoC container.

You can think of it as Spring’s brain and memory.

What does this IoC container do?

It looks at your project and searches for classes marked with things like:

@Component
@Service
@Repository
@Controller

These annotations tell Spring:

“You are allowed to manage this class.”

Spring then creates objects of those classes and stores them inside the ApplicationContext.

These objects are called Spring Beans.

Bean→ the object Spring creates from that class

Context → where Spring stores and manages those objects

In simple words:
Spring creates a context (IoC container), puts your beans inside it, and then runs your application using those beans.