Spring Bean Lifecycle: Creation to Destruction

🧠 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

💡 From a Small Spring Confusion to a Big Backend Realisation 🚀 Recently, while revising Spring fundamentals, I got stuck on a very simple doubt: 👉 Why does Spring create a proxy for @Configuration classes but not for normal @Component beans? At first, it sounded like a minor annotation difference. But digging deeper revealed an important concept about how the Spring container actually guarantees singleton behaviour. ✅ For @Component beans Spring creates the bean once during application startup and stores it in the singleton cache. Every injection or lookup simply returns the same instance. No interception or proxy is needed because developers don’t directly control the bean creation logic. ✅ For @Configuration classes Developers define @Bean methods that can call each other like normal Java methods. Without control, each method call could create a new object and break the singleton guarantee. This is where Spring uses CGLIB proxying. The proxy intercepts internal @Bean method calls and converts them into container lookups, ensuring that the already-created singleton bean is returned instead of creating a new instance. 🔥 Key Insight: Proxy is not created to “make beans singleton.” It is created to prevent accidental multiple object creation when bean factory methods are invoked directly. Understanding this changed the way I look at Spring — it’s not just annotations and auto-wiring, but a carefully designed lifecycle and container mechanism that protects consistency in large backend systems. Sometimes a small confusion leads to the biggest clarity 🙂 #SpringBoot #Java #BackendEngineering #Microservices #LearningJourney #SoftwareEngineering #SystemDesign

✨ Spring Framework 🚀 Today I went deeper into Dependency Injection and Autowiring in Spring and understood how Spring automatically manages dependencies. 🔹 @Autowired (Field, Setter, Constructor Injection) 🔹 How Spring resolves dependencies internally 🔹 Common issues (NoUniqueBeanDefinitionException) 🔹 Using @Qualifier to resolve ambiguity 🔹 Comparison of XML vs Annotation configuration Understanding these concepts made it clearer how Spring reduces manual object creation and handles dependencies efficiently 💡 📌 Also implementing these concepts in code alongside notes. Consistency is the goal 🚀 #SpringFramework #JavaDeveloper #BackendDevelopment #LearnInPublic #SpringBoot #CodingJourney

Stop labeling your Spring Beans randomly! 🛑 I see many projects where @Component, @Service, and @Repository are used interchangeably. They all register a Bean in the context, so they are the same, right? Not exactly. Using the right stereotype is about Communication and Semantics. 🔹 @Service: Clearly states: "This is where the business logic lives." It's your domain's heart. 🔹 @Repository: Signals: "I talk to the database." Spring provides an extra layer of magic here: it automatically translates platform-specific exceptions (like SQLException) into Data Access Exceptions. 🔹 @Component: The generic catch-all. Use it for utility classes or anything that doesn't fit the service/repository pattern. Tip: Using the correct label makes your code readable for the next dev. It tells a story about what each class is responsible for before they even read a single line of implementation. How strict is your team with stereotyping their Spring components? Let’s talk below! 👇 #Java #SpringBoot #SoftwareArchitecture #CleanCode #Backend #SpringFramework #CleanDesign

🚨 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

Dev Notes #03 Not every dev note is about something that worked, While building the authentication system, my controller was calling a method that didn't exist in my service layer yet. And what was the fix? Adding the missing method. But here's what was actually worth noting down: In Spring Boot, the Controller handles incoming requests, the Service holds the business logic, and the Repository talks to the database. They're separate layers on purpose, each has one job. When the controller tries to do something the service hasn't defined yet, it breaks. And according to me, that's a good thing since it means your layers are actually separated the way they should be. Who would have though that debugging would be so insightful about architecture. #Java #SpringBoot #BackendDevelopment #Debugging #LearningInPublic

The @Transactional Proxy Pitfall Think slapping @Transactional on a method guarantees database rollback on failure? Think again. 🚨 One of the most common critical bugs I see in Spring Boot applications isn't a logic error—it's a misunderstanding of how Spring AOP (Aspect-Oriented Programming) works under the hood. Enter the Self-Invocation Problem. If you have a non-transactional method processOrder() that calls a @Transactional method saveToDatabase() within the exact same class, that transaction will never start. If an exception is thrown, your data will not roll back. 💥 Why does this happen? Spring manages transactions using proxies. When an external class calls your bean, it hits the proxy first, which starts the transaction. But when you make an internal method call (calling this.saveToDatabase()), you are bypassing the proxy entirely and calling the raw object. No proxy = no transaction. How to fix it: 1️⃣ Refactor: Move the @Transactional method to a separate dedicated Service class (Best Practice). 2️⃣ Self-Injection: Inject the class into itself using @Autowired or constructor injection, and call the method via the injected instance. 3️⃣ AspectJ: Switch from proxy-based AOP to AspectJ weaving (Heavyweight, but solves proxy limitations). Understanding the framework's internal mechanics is the difference between writing code that compiles and writing systems that are truly fault-tolerant. Have you ever been bitten by the Spring proxy self-invocation trap? What is your favorite obscure Spring Boot "gotcha"? Let's geek out in the comments! 👇 Tags: #Java #SpringBoot #SoftwareEngineering #BackendDevelopment #AdvancedJava #SystemDesign #CodingTips

🧠 After learning Dependency Injection, I had one big question 👀 Who actually creates these objects in Spring Boot, and when? Today I explored the Spring Bean Lifecycle 🚀 Simple flow 👇 1️⃣ Spring container starts 2️⃣ Bean object is created 3️⃣ Dependencies are injected 4️⃣ Bean becomes ready to use 5️⃣ Bean is destroyed when the app shuts down What made this even more interesting 👇 ✅ @PostConstruct → runs after bean creation ✅ @PreDestroy → runs before bean cleanup 💡 My takeaway: Spring doesn’t just inject dependencies — it also manages the entire lifecycle of the object. The more I learn this framework, the more beautifully engineered it feels ⚡ #Java #SpringBoot #BeanLifecycle #BackendDevelopment #LearningInPublic

🚀 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