Spring Bean Lifecycle Explained in 5 Steps

🧠 After learning the Spring Bean Lifecycle, I explored another powerful concept today 👀 Singleton vs Prototype Bean Scope in Spring Boot 🚀 The default scope in Spring is singleton 👇 ✅ Only one object instance is created ✅ Shared across the whole application ✅ Best for services, repositories, controllers Then comes prototype 👇 🔁 A new object is created every time it is requested This makes it useful for: ✅ temporary objects ✅ stateful helpers ✅ per-request custom processing 💡 My takeaway: Bean scope directly changes how Spring manages memory and object reuse. Small annotations can completely change runtime behavior ⚡ #Java #SpringBoot #BeanScope #BackendDevelopment #LearningInPublic

🚨 Why I stopped using field injection in Spring Boot I used to write this: @Autowired private UserService userService; Looks clean… but caused real issues. ❌ Problems: * Hard to test * Hidden dependencies * NullPointer risks in edge cases ✅ Now I always use constructor injection: public UserController(UserService userService) { this.userService = userService; } 💥 Real benefit: While writing unit tests, I realized I could mock dependencies easily without Spring context. 💡 Takeaway: Field injection is convenient. Constructor injection is production-safe. Small change. Big impact. #Java #SpringBoot #BackendDevelopment #SoftwareEngineering  #Microservices #RESTAPI #SystemDesign  #DeveloperLife #100DaysOfCode

Spring Boot Bean Lifecycle — Most developers ignore this 🔥 Do you know what happens before your bean is ready? Here’s the flow 👇 1️⃣ Bean Instantiation 2️⃣ Dependency Injection 3️⃣ @PostConstruct runs 4️⃣ Bean is ready to use ✅ And before shutdown: 👉 @PreDestroy is called 💡 Why it matters: ✔ Resource initialization ✔ Cleanup logic ✔ Better control over application lifecycle ⚠️ Mistake: Putting heavy logic inside constructors ❌ 👉 Use @PostConstruct instead Understanding lifecycle = writing smarter Spring Boot apps 🚀 #SpringBoot #Java #BackendDeveloper

🚀 30 Days of Spring Boot – Day 2 Today I explored one of the core foundations of Spring — Beans & Their Management. 🔹 What I learned: ✅ Spring Bean A Bean is a Java object managed by the Spring IoC container. Instead of creating objects using new, Spring handles creation, lifecycle, and dependency injection. ✅ @Bean Annotation Used to manually define a Bean inside a @Configuration class. It gives full control over object creation — especially useful for third-party classes or custom configurations. 💡 Even though we use new inside a @Bean method, it is executed only once by Spring (Singleton scope by default) and reused across the application. ✅ Bean Scope Defines how many instances Spring creates: Singleton → Single shared instance (default) Prototype → New instance every time Request → Per HTTP request Session → Per user session 🔥 Key Takeaway: “Write new once, let Spring manage and reuse the object everywhere.” 📌 Strengthening fundamentals step by step. #SpringBoot #Java #BackendDevelopment #LearningJourney #100DaysOfCode #Microservices

Yesterday: “It’s working perfectly 😌” Today: Application failed to start. Same code. Same logic. Different story. Welcome to Spring Boot reality 👇 → One missing bean = full system collapse → One wrong config = hours gone → One hidden null = chaos unleashed → One DB hiccup = everything breaks And suddenly… you’re not coding anymore, you’re investigating. Logs become clues. Stack traces become stories. Debugging isn’t pain — it’s where real backend thinking begins. Because great developers don’t fear crashes… they understand them. ⚡ #SpringBoot #Java #BackendDevelopment #Debugging #BuildInPublic

🧠 After learning Request Scope, I explored something even more practical today 👀 **Session Scope in Spring Boot** 🌐 Here’s the simple idea 👇 ✅ One bean instance is created per **user session** ✅ The same object is reused across multiple requests from the same user ✅ Different users get different objects This makes it useful for 👇 🔹 user login data 🔹 shopping cart 🔹 session-based preferences 🔹 multi-step workflows 💡 Quick difference: Request Scope → new object every request Session Scope → same object for the same user 💡 My takeaway: Session scope helps maintain **user-specific state across multiple requests** without recreating objects again and again ⚡ #Java #SpringBoot #SessionScope #BackendDevelopment #LearningInPublic

🚀 Day 20/100: Spring Boot From Zero to Production Topic: Custom Auto-Configuration We covered Auto-Configuration. We covered disabling it. But does it stop there? Nope. 👀 Spring Boot lets you build your own auto-configuration too. 🔧 But, How It Works? You create a @Configuration class and slap conditionals on it. Spring Boot only loads it if your conditions are met. Two most common ones: @ConditionalOnClass → Load only if a class exists on the classpath @ConditionalOnProperty → Load only if a property is set in application.properties 💡 See the code attached below. ⬇️ No DataSource on classpath? → Skipped entirely db.enabled=false? → Skipped entirely Bean already defined by user? → Your default is skipped ✅ 📌 Don't forget to register it In META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports: -> com.yourpackage.MyDataAutoConfiguration Without this, Spring Boot won't pick it up. Checkout the previous posts on Auto-Config & disabling it to better understand the sequence. See you in the next one! #Java #SpringBoot #SoftwareDevelopment #100DaysOfCode #Backend #AutoConfiguration

Fixing a Real Spring Boot Error (and what it taught me) While building a simple REST API, I encountered this error:  ClassCastException: Product cannot be cast to Prodcut 🔍 What went wrong? I unknowingly created two different classes: Product ✅ (correct model) Prodcut ❌ (typo) Then I tried to cast one into another — which caused the application to crash. Why this error happens In Java, even a small typo creates a completely new class.So: Product ≠ Prodcut Java treats them as entirely different types, and casting between them is not allowed. #Java #SpringBoot #Debugging #BackendDevelopment #CodingJourney #SoftwareEngineering

Healthy services can still create a broken system. That lesson took me longer to learn than it should have. Early on, I used to judge systems service by service: Is inventory up? Is pricing up? Is payment up? But production does not care whether each box is green in isolation. It cares about the full request path. That changed how I look at failures, tracing, retries, and resilience. A lot of systems are not failing at the component level. They are failing at the interaction level. What taught you that lesson? #Java #SpringBoot #DistributedSystems #Microservices #BackendEngineering