Jānis Ošs’ Post

💡 Understanding Collection-Based Dependency Injection in Spring When we talk about Dependency Injection (DI) in Spring, most of us think about injecting a single object. But did you know you can inject multiple beans at once using collections? 🤔 Let’s break it down in a simple way 👇 🔹 What is Collection-Based DI? Instead of injecting one object, Spring can inject a list, set, or map of beans into your class. 👉 This is useful when you have multiple implementations of the same interface. 🔹 What’s Happening Here? ✅ Spring scans all beans of type PaymentService ✅ It collects them into a List ✅ Injects them automatically into PaymentProcessor 🔹 Other Supported Collections You can also use: ✔ List<Interface> ✔ Set<Interface> ✔ Map<String, Interface> → Key = bean name Example: Map<String, PaymentService> paymentMap; 🔹 Why is this Useful? ✔ Helps implement strategy pattern easily ✔ Avoids manual bean selection ✔ Makes code more flexible & scalable 🔹 Pro Tip 🚀 Spring injects collections in a specific order if you use @Order or @Priority. 🔚 Summary Collection-based DI = Inject multiple beans → Handle dynamically → Write cleaner code If you're learning Spring deeply, this concept is a game changer when building scalable systems 🔥 #Java #SpringBoot #DependencyInjection #BackendDevelopment #CleanCode

Ever spent hours debugging a “simple” boolean bug… only to realize it’s not your logic, but your field name? 😅 Recently, I ran into a very tricky issue while making a WebClient call between two microservices. 👉 I was sending: "eCollectDbCallFlag": true 👉 But receiving: "eCollectDbCallFlag": false Everything looked correct: ✔ Same DTO on both sides ✔ Proper JSON ✔ Added @JsonProperty ✔ Logging showed correct request Still… the value kept turning false on the receiving service. After digging deeper, the real culprit turned out to be Jackson’s boolean property naming edge case. 💥 The field name eCollectDbCallFlag was causing ambiguity during deserialization, so Jackson silently ignored it and applied the default value (false). 🚀 The surprising fix? Just renaming the field to: auBankEcollectDbCallFlag And everything started working perfectly. 🔍 Key Takeaway: When working with Spring Boot + Kotlin + Jackson: ->Be careful with boolean field names ->Avoid ambiguous prefixes like e, is, has ->If something “impossible” happens → suspect serialization before logic Sometimes the bug isn’t in your code… …it’s in how your code is interpreted. #Java #Kotlin #SpringBoot #Microservices #Debugging #BackendDevelopment #SoftwareEngineering

I understood Dependency Injection… but I was confused about how it actually works in code. Then I learned about @Autowired What does @Autowired do? It tells Spring: “Inject the required dependency here automatically.” --- Without @Autowired: You manually create objects → more code, tight coupling With @Autowired: Spring finds and injects the object → cleaner code --- How it works (simple): Spring scans your project → Finds matching beans → Injects them where @Autowired is used --- Why it matters: • Reduces boilerplate code • Improves maintainability • Enables loose coupling --- In simple terms: @Autowired = “Spring, you handle this for me.” --- Learning step by step and building strong fundamentals Next: I’ll explain how Spring Boot handles REST APIs internally. #SpringBoot #Java #BackendDevelopment #LearningInPublic #FullStackDeveloper

🚀 Understanding Autowire byType in Spring In Spring Framework, Autowire byType is a type of automatic dependency injection where Spring matches a bean based on its class type. 👉 In simple terms: Spring injects a dependency if it finds a bean of the same type. 🔹 How it works? ✔ Spring checks the data type of the property ✔ Finds a bean with the same class type ✔ Injects it automatically 🔹 Example: class Student { private Address address; public void setAddress(Address address) { this.address = address; } } <bean id="addressBean" class="com.example.Address"/> <bean id="student" class="com.example.Student" autowire="byType"/> 👉 Here, Spring injects the Address object based on its type, not the name. 🔹 Key Points ✔ Matches based on class type ✔ Works with setter injection ✔ Fails if multiple beans of same type exist ❌ 💡 Pro Tip: Use @Qualifier along with @Autowired when multiple beans of the same type are present. ✨ Understanding byType helps you build flexible and loosely coupled applications! Anand Kumar Buddarapu #Java #SpringBoot #Autowiring #DependencyInjection #BackendDevelopment #SoftwareEngineering #LearningJourney

A quick question that made me curious: What actually happens behind the scenes when we use @Transactional in Spring Boot? Most of us just add the annotation and trust it to handle everything. But under the hood, something interesting is happening. Spring doesn’t directly modify your method. Instead, it creates a proxy around the bean. So when a transactional method is called, the flow looks like: Client → Proxy → Transaction Manager → Your Method → Commit/Rollback Here’s what the proxy does: • Starts a transaction before method execution • Executes your business logic • Commits if everything is fine • Rolls back if an exception occurs But here’s another catch 👇 Not all exceptions trigger rollback. By default, Spring only rolls back for: • Runtime exceptions (RuntimeException) • Errors (Error) But checked exceptions (like IOException, SQLException) 👉 do NOT trigger rollback by default So sometimes: • Your code throws an exception • But the transaction still commits 😳 If you want rollback for all exceptions, you need: @Transactional(rollbackFor = Exception.class) And one more important catch: The proxy only works when the method is called from outside the bean. If one method inside the same bean calls another method annotated with @Transactional, the call bypasses the proxy. So the transaction may not even start. That’s why sometimes: • Transactions don’t work as expected • Rollbacks don’t happen • Bugs are hard to trace Spring isn’t “magic” — it’s just smart use of proxies and AOP. Now the interesting question: If method A and method B are in the same bean, and B is annotated with @Transactional, and A calls B internally… 👉 How would you make sure the transaction actually works? #SpringBoot #BackendEngineering #Java #SystemDesign #Transactional #AOP

🔄 Spring Bean Lifecycle – From Creation to Destruction While working with Spring, one concept that really helped me understand how things run internally is the Bean Lifecycle. A Spring Bean goes through multiple stages from the moment it is created till it gets destroyed. Knowing this flow makes debugging and customization much easier. 👉 1. Instantiation Spring container creates the bean instance using constructor or factory method. 👉 2. Dependency Injection All required dependencies are injected (via constructor/setters/fields). 👉 3. Initialization Spring calls lifecycle callbacks like: @PostConstruct InitializingBean.afterPropertiesSet() custom init-method 👉 4. Bean Ready for Use Now the bean is fully initialized and ready to serve the application. 👉 5. Destruction Before removing the bean, Spring calls: @PreDestroy DisposableBean.destroy() custom destroy-method 💡 Why it matters? Understanding lifecycle hooks allows better control over resource management, logging, and custom initialization logic. 📌 For me, learning this made Spring feel less like “magic” and more predictable. #Java #SpringBoot #BackendDevelopment #SoftwareEngineering #LearningJourney

🧠 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

Hi everyone 👋 Continuing the Spring Boot Validation Series Part 27 👇 📌 Validation Annotation – @NotNull The @NotNull annotation is used to ensure that a field cannot be null 👇 🔹 Why do we use @NotNull? When we receive data from users or APIs, we want to make sure some fields are always present. 👉 @NotNull helps us enforce this rule. 🔹 Simple Example - public class User { @NotNull private String name; private String email; } @PostMapping("/users") public String createUser(@Valid @RequestBody User user) { return "User created"; } 👉 If name is null → validation fails ❌ 🔹 Important Point 👉 @NotNull checks only for null value It does NOT check: Empty string ❌ Blank value ❌ 🔹 Difference @NotNull - Value should not be null @NotEmptyNot - null + not empty\ @NotBlankNot - null + not empty + no only spaces. 🔹 Example for clarity @NotNull // allows "" (empty) @NotEmpty // does NOT allow "" @NotBlank // does NOT allow "" or " " 🔹 In simple words @NotNull makes sure that the value is not null, but it can still be empty. 👉 🧠 Quick Understanding - Checks only for null - Does not validate empty or blank - Used with @Valid - Important for required fields #SpringBoot #Java #Validation #NotNull #BackendDevelopment #LearningInPublic

New to Spring Boot? You'll see these annotations in every project. Here's what they actually do: @SpringBootApplication → Entry point. Combines @Configuration, @EnableAutoConfiguration, @ComponentScan @RestController → Marks a class as an HTTP request handler that returns data (not views) @Service → Business logic layer. Spring manages it as a bean @Repository → Data access layer. Also enables Spring's exception translation @Autowired → Inject a dependency automatically (prefer constructor injection instead) @GetMapping / @PostMapping / @PutMapping / @DeleteMapping → Maps HTTP methods to your handler methods @RequestBody → Deserializes JSON from request body into a Java object @PathVariable → Extracts values from the URL path Bookmark this. You'll refer back to it constantly. Which annotation confused you the most when starting out? 👇 #Java #SpringBoot #Annotations #BackendDevelopment #LearningInPublic

🚀 Spring Framework 🌱 | Day 2 – Dependency Injection (DI) Today I understood Dependency Injection not just as a concept… but as a mindset shift 💡 👉 In real life, DI is everywhere. Think about this 👇 ☕ When you order tea in an office You don’t go to the kitchen, buy milk, sugar, tea powder and make it yourself. 👉 Someone provides it to you. 🚗 When you book a cab You don’t build the car or hire a driver manually. 👉 The system injects the service you need. 🏢 In a company project A developer doesn’t create every object manually. 👉 Framework like Spring injects dependencies automatically. 💡 Same happens in Spring Instead of: ❌ Creating objects using "new" We let Spring: ✅ Create objects ✅ Manage them ✅ Inject wherever needed 🔹 How it works internally (simple view): 👉 Spring scans classes 👉 Creates beans in IOC container 👉 Finds dependencies 👉 Injects them using annotations 🔥 Why this matters? - Loose coupling - Easy testing - Clean & scalable code 👉 Small concept, but it completely changes how you build applications. #SpringFramework #Java #BackendDevelopment #LearningJourney #SpringBoot #TechGrowth