Spring Boot

Ah, the timeless classic in the world of software engineering – the production issue that decides to make its grand entrance on a Friday night. :police_car_light: One such incident happened last week. Turns out, the bug was in one of the features that I recently worked on. We are passing an entity to the Jackson’s Object Mapper to serialize it and return it as a JSON. The entity has some fields which are configured to lazy-load by Hibernate. Now, while serializing the entity we faced an unexpected behaviour. This was the bug that was breaking my API in production. However, I was a bit lucky here that this issue was confined to a particular scenario only. :face_with_tongue:

Quartz is a feature-rich open-source Java library used to schedule jobs. The core components of this library are Job, JobDetail, Trigger, and Scheduler. The JobDetail is where the job definition lies. The Trigger contains the instructions about when the job should get executed and Scheduler who runs the Job. Spring Boot Maven Dependency for Quartz library # <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-quartz</artifactId> </dependency> The Core Components # Job: We create our own jobs by extending the QuartzJobBean class that implements Job interface. This interface has one method execute(JobExecutionContext context), which is overriden by the QuartzJobBean. This is where the scheduled task runs and the information on the JobDetail and Trigger is retrieved using the JobExecutionContext. The QuartzJobBean also gives us an abstract method executeInternal(JobExecutionContext context). Your Job class needs to override the executeInternal(...) method and should contain the code you want to get processed when the job gets executed. public class MyJob extends QuartzJobBean { ... @Override protected void executeInternal(@NonNull JobExecutionContext context) { ... } } JobDetail: Defining the Job. JobDetail jobDetail = JobBuilder.newJob(MyJob.class) .withIdentity(jobName) .storeDurably() .requestRecovery() .usingJobData(jobDataMap) .build(); Trigger: Defining the schedule upon which the job will be executed. Trigger jobTrigger = TriggerBuilder.newTrigger() .forJob(jobDetail) .startAt(scheduledAt) .withIdentity(triggerName) .build(); Scheduler: This is the main API for interacting with the Quartz Scheduler. We can get an instance of the Scheduler from the SchedulerFactoryBean. public class MyJob extends QuartzJobBean { @Autowired SchedulerFactoryBean schedulerFactoryBean; ... public void start(...) { Scheduler timer = schedulerFactoryBean.getScheduler(); timer.start(); ... timer.scheduleJob(jobDetail, jobTrigger); } Job Persistence # Quartz gives us JobStore for storing all the Job, Trigger and Scheduler related data.

Feign Client allows you to abstract the mechanics of calling a REST service. You need to configure and annotate the Feign Client interface to call a RESTful web service by making a simple Java method call.

I was listening to Uncle Bob Martin’s lecture on YouTube last night. His No ‘side-effects’ advice hit me and made me realize that I was doing something in my code that I shouldn’t be doing it that way.

I’m currently working on a microservices-based Spring Boot application, where I’m using Logback as my logging framework. The application is now running live on a remote server. Since I don’t have access to the server, I don’t get to see the logs when I want to see them or when there is some error. I have to ask someone from the sysadmin team to send me the log file every time and wait for their response. This kind of human dependency eats up a decent amount of time in any software development lifecycle. I try to avoid such dependencies and seek to circumvent them. So, I have written a simple snippet of code that can read the log file from the server filesystem and send it back to me in an API response.

We usually use if-else or switch statements to write our logical conditions in our code. There is nothing to worry about as long as your list of logical conditions is short.