Spring Boot Scheduling Issue: Duplicate Task Execution

Spent 10 minutes wondering why my Spring Boot @Scheduled task was not running. The code looked fine: @Scheduled(fixedRate = 5000) public void runTask() { System.out.println("Task running..."); } No errors. App started fine. But the task never executed. The problem: Missing @EnableScheduling on the main application class. The fix: @SpringBootApplication @EnableScheduling public class MyApplication { public static void main(String[] args) { SpringApplication_run(MyApplication.class, args); } } One annotation. That was it. Spring does not warn you when scheduling is disabled. It just silently ignores your @Scheduled methods. What scheduling issue has caught you off guard? #Java #SpringBoot #Scheduling #Debugging #BackendDevelopment

🚀 Spring Boot Series #006 Spring Bean Lifecycle — The Hidden Magic Behind Your Application Ever wondered what really happens when your Spring Boot app starts? It’s not just objects being created… it’s a well-orchestrated lifecycle 🔄 Let’s break it down 👇 🔹 1. 𝗕𝗲𝗮𝗻 𝗜𝗻𝘀𝘁𝗮𝗻𝘁𝗶𝗮𝘁𝗶𝗼𝗻 Spring creates the bean instance (using constructor or factory method). 👉 “Object is born” — but not ready yet. 🔹 2. 𝗗𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 Spring injects required dependencies (@Autowired, constructor injection, etc.) 👉 Now your bean starts gaining power ⚡ 🔹 3. 𝗔𝘄𝗮𝗿𝗲 𝗜𝗻𝘁𝗲𝗿𝗳𝗮𝗰𝗲𝘀 (Optional but powerful) Spring injects internal context via interfaces like: BeanNameAware ApplicationContextAware 👉 Your bean becomes Spring-aware 🧠 🔹 4. 𝗕𝗲𝗮𝗻 𝗣𝗼𝘀𝘁-𝗣𝗿𝗼𝗰𝗲𝘀𝘀𝗶𝗻𝗴 (Before Init) Custom logic via BeanPostProcessor 👉 Great place for custom proxies, logging, auditing 🔹 5. 𝗜𝗻𝗶𝘁𝗶𝗮𝗹𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗣𝗵𝗮𝘀𝗲 This is where your bean becomes fully ready! Ways to initialize: @PostConstruct InitializingBean.afterPropertiesSet() Custom init-method 👉 “I’m ready to serve!” 💪 🔹 6. 𝗕𝗲𝗮𝗻 𝗣𝗼𝘀𝘁-𝗣𝗿𝗼𝗰𝗲𝘀𝘀𝗶𝗻𝗴 (After Init) Another chance to modify the bean (AOP magic happens here ✨) 🔹 7. 𝗕𝗲𝗮𝗻 𝗶𝘀 𝗥𝗲𝗮𝗱𝘆 𝘁𝗼 𝗨𝘀𝗲 Finally, your bean is in action 🎯 🔹 8. 𝗗𝗲𝘀𝘁𝗿𝘂𝗰𝘁𝗶𝗼𝗻 𝗣𝗵𝗮𝘀𝗲 When the app shuts down: @PreDestroy DisposableBean.destroy() Custom destroy-method 👉 Cleanup resources 🧹 #SpringBeansLifecycle #Java #BackendDevelopment #SpringBoot #SoftwareEngineering #SpringBootwithVC

🚀 Spring Boot Exception Handling with @ExceptionHandler Most developers handle errors reactively — scattering try/catch blocks everywhere. There's a cleaner way. Spring Boot's @ExceptionHandler lets you centralize error handling right where it belongs: in your controller. Here's the pattern that changes everything: @RestController @RequestMapping("/users") public class UserController { @GetMapping("/{id}") public UserDto getUser(@PathVariable Long id) { return userService.findById(id); // throws UserNotFoundException } @ExceptionHandler(UserNotFoundException.class) public ResponseEntity<ErrorResponse> handleUserNotFound(UserNotFoundException ex) { ErrorResponse error = new ErrorResponse(404, ex.getMessage()); return ResponseEntity.status(404).body(error); } } What makes this powerful: ✅ Clean separation of business logic and error handling ✅ Consistent JSON error responses for clients ✅ No more polluted service/controller methods ✅ Type-safe — each exception type gets its own handler The key insight? @ExceptionHandler scope is per-controller. If you want application-wide handling, you'll need @ControllerAdvice — and that's exactly what we'll cover tomorrow! 🎯 #Java #SpringBoot #BackendDevelopment #ExceptionHandling #REST #CleanCode

🚀 Day 14/100: Spring Boot From Zero to Production Topic: Spring Profiles & Environments Today’s topic is one of my favorites. We just covered configuration files, but how do we handle them when moving from our laptops to a live server? Enter Spring Profiles. 🛠️ 🤔 What is a Profile? Think of a Profile as a "mode" for your application. You want the same code to run everywhere, but with different settings (like a local H2 database for testing vs. a heavy-duty MySQL for Production). Consistency: You don't change code; you just change the profile. Flexibility: Easily switch between dev, test, and prod environments. 🔄 ⚡ The Execution Flow: This is the part you need to remember: application.properties (or .yml) always loads first. It’s your base layer. Global Configs: Put shared settings in the default file. The Override: If you activate a specific profile (like prod), those settings load next. Priority: If a setting exists in both, the active profile overrides the default. It’s like a smart layering system! 🍰 📂 How to Organize Them: You have two main ways to structure your environment settings: Separate Files: Create application-dev.yml and application-prod.yml. This is best for large projects to keep things clean. Single File: In YAML, you can use --- to separate environments in one file. Great for smaller scopes! 📄 Working with profiles makes your app "environment-aware" and professional. Stay tuned for more Spring Boot magic! ✨ #Java #SpringBoot #SoftwareDevelopment #100DaysOfCode #Backend

Spent 15 minutes wondering why my Spring Boot application was not picking up environment variables. The code looked fine: @Value("${API_KEY}") private String apiKey; No errors. App started fine. But apiKey was always null. The problem: Environment variables use underscores, but Spring expects dots in property names by default. The fix: Use relaxed binding or set it correctly in application-properties. spring.application.api-key=${API_KEY} Then inject it: @Value("${spring.application.api-key}") private String apiKey; One mapping. That was it. Spring does not warn you when it cannot resolve an environment variable. It just injects null and moves on. What environment variable issue has caught you off guard? #Java #SpringBoot #Debugging #BackendDevelopment

🚀 Day 66/100 - Spring Boot - Auto Restart with DevTools One of the most useful features of Spring Boot DevTools is automatic application restart during development... Instead of manually stopping and restarting your application every time you make a change, DevTools does it for you❗ ➡️ How Auto Restart Works? DevTools continuously monitors classpath files. When a change is detected (for example, when a .class file is updated after saving code), Spring Boot automatically restarts the application context. This creates a much faster development feedback loop. ➡️ Example Workflow 1️⃣ Modify a controller method in your IDE 2️⃣ Save the file 3️⃣ DevTools detects the change 4️⃣ Spring Boot restarts automatically 5️⃣ Refresh the browser → changes appear immediately ➡️ Benefits 🔹Eliminates the need to manually stop and start the app 🔹Improves feedback loop during development ➡️ Excluding Certain Files from Being Monitored Sometimes you don't want DevTools to restart for certain file changes (like static assets)... You can configure exclusions in application.properties: spring.devtools.restart.exclude=static/**,public/** This prevents restarts when files in these directories change. Previous post - Spring Boot Developer Tools: https://lnkd.in/djgPTRBJ #100Days #SpringBoot #DevTools #DeveloperProductivity #Java #BackendDevelopment #WebDevelopment #SoftwareEngineering

Spent 10 minutes wondering why my Spring Boot application was not picking up environment variables. The code looked fine: @Value("${DATABASE_URL}") private String databaseUrl; No errors at startup. But the value was always null. The problem: I was using underscores in the property name, but Spring expects dots or lowercase with hyphens. The fix: @Value("${database.url}") private String databaseUrl; And in application_properties: database.url=${DATABASE_URL} One mapping. That was it. Spring does not automatically convert environment variable names to property names. You need to map them explicitly. What environment variable issue has caught you off guard? #Java #SpringBoot #EnvironmentVariables #Debugging #BackendDevelopment

Spring Boot Magic #4 ✨ — Starter Dependencies One thing I feel is underrated in Spring Boot… is how powerful starter dependencies actually are. We use them every day, but rarely think about how much work they’re saving us. Just add one dependency… and boom 💥 Everything is auto-configured and ready to use. Some underrated but super useful starters 👇 👉 spring-boot-starter-validation Handle validations with simple annotations like @NotNull, @Email — clean & easy 👉 spring-boot-starter-data-jpa No need to write basic SQL — just interfaces and you’re good to go 👉 spring-boot-starter-security Add authentication & authorization with minimal setup 👉 spring-boot-starter-actuator Production-ready endpoints for health, metrics, monitoring 👉 lombok (not a starter but a lifesaver 😄) Removes boilerplate like getters, setters, constructors We use these almost daily… but don’t always realize how much complexity they hide. Sometimes, the real magic is just one dependency away 🚀 #SpringBoot #Java #BackendDevelopment #CleanCode #DeveloperLife

Spring Boot Annotations — The Backbone of Every Application When I started learning Spring Boot, annotations felt confusing… But once I understood them, everything became much simpler. In simple terms: Annotations tell Spring Boot what to do and how to manage your code. --- 🔹 Some important ones: @SpringBootApplication → Entry point of the app ✅ @RestController → Handles API requests ✅ @Service → Business logic layer ✅ @Repository → Database interaction ✅ @Autowired → Injects dependencies automatically ✅ @RequestMapping → Maps HTTP requests --- Why annotations matter: Reduce boilerplate code Enable Dependency Injection Make applications modular & scalable Help Spring manage everything behind the scenes --- Instead of writing everything manually, Spring Boot = “Just add annotations, I’ll handle the rest.” --- Currently learning and applying these concepts step by step #SpringBoot #Java #BackendDevelopment #Annotations #LearningInPublic #FullStackDeveloper

Spent 25 minutes wondering why my Spring Boot application was logging the same message twice. The code looked fine: @Slf4j @Service public class OrderService {   public void processOrder(Order order) {     log.info("Processing order: {}", order.getId());     // processing logic   } } No errors. App worked fine. But every log message appeared twice in the console. The problem: I had both Logback and Log4j2 on the classpath. Spring Boot auto-configured both logging frameworks. The fix: Exclude one of them in pom.xml. <dependency>   <groupId>org.springframework.boot</groupId>   <artifactId>spring-boot-starter</artifactId>   <exclusions>     <exclusion>       <groupId>org.springframework.boot</groupId>       <artifactId>spring-boot-starter-logging</artifactId>     </exclusion>   </exclusions> </dependency> One exclusion. That was it. Spring Boot does not warn you when multiple logging frameworks are on the classpath. It just logs everything twice. What duplicate logging issue has caught you off guard? #Java #SpringBoot #Debugging #BackendDevelopment