If you are already using SpringApplication from Spring Boot, why not finish the job and use @EnableAutoConfiguration as well, and also the Maven plugin (see for example this guide)? That way you will get something working pretty quickly and you can always add your own features later.
If you are already using SpringApplication from Spring Boot, why not finish the job and use @EnableAutoConfiguration as well, and also the Maven plugin (see for example this guide)? That way you will get something working pretty quickly and you can always add your own features later.
If the first argument to the CommandLineJobRunner is your @Configuration FQCN instead of a resource path, the ClassPathXmlApplicationContext constructor that's called from the CommandLineJobRunner's start() method will break.
int start(String jobPath, String jobIdentifier, String[] parameters, Set<String> opts) {
ConfigurableApplicationContext context = null;
try {
context = new ClassPathXmlApplicationContext(jobPath);
If you've already written a class with a main(), that replaces the CLJR, you shouldn't be passing CLJR as the class name in the command line. Pass that instead.
Solution 1: Inside file application.properties add
spring.batch.job.names=wordScrubber
If you have many jobs
spring.batch.job.names=wordScrubber,foo,bar
then run
mvn spring-boot:run
Solution 2: Best practice way is
$ java -jar myapp.jar --server.port=7070 someParameter=someValue
Not use Maven parameter, use parameter when run JAR file. See reference document at https://docs.spring.io/spring-boot/docs/current/reference/html/howto.html#howto.batch.running-from-the-command-line
mvn clean spring-boot:run -Dspring.batch.job.names=wordScrubber
cleanto overwrite previously compiled files intarget/classes.spring-boot:runstart ups spring boot.-Dspring.batch.job.names=<jobName>run a specific batch job.
Just set the "spring.batch.job.names=myJob" property. You could set it as SystemProperty when you launch your application (-Dspring.batch.job.names=myjob). If you have defined this property, spring-batch-starter will only launch the jobs, that are defined by this property.
To run the jobs you like from the main method you can load the the required job configuration bean and the JobLauncher from the application context and then run it:
@ComponentScan
@EnableAutoConfiguration
public class ApplicationWithJobLauncher {
public static void main(String[] args) throws BeansException, JobExecutionAlreadyRunningException, JobRestartException, JobInstanceAlreadyCompleteException, JobParametersInvalidException, InterruptedException {
Log log = LogFactory.getLog(ApplicationWithJobLauncher.class);
SpringApplication app = new SpringApplication(ApplicationWithJobLauncher.class);
app.setWebEnvironment(false);
ConfigurableApplicationContext ctx= app.run(args);
JobLauncher jobLauncher = ctx.getBean(JobLauncher.class);
JobParameters jobParameters = new JobParametersBuilder()
.addDate("date", new Date())
.toJobParameters();
if("1".equals(args[0])){
//addNewPodcastJob
Job addNewPodcastJob = ctx.getBean("addNewPodcastJob", Job.class);
JobExecution jobExecution = jobLauncher.run(addNewPodcastJob, jobParameters);
} else {
jobLauncher.run(ctx.getBean("newEpisodesNotificationJob", Job.class), jobParameters);
}
System.exit(0);
}
}
What was causing my lots of confusion was that the second job were executed, even though the first job seemed to be "picked up" by the runner... Well the problem was that in both job's configuration file I used standard method names writer(), reader(), processor() and step() and it used the ones from the second job that seemed to "overwrite" the ones from the first job without any warnings...
I used though an application config class with @EnableBatchProcessing(modular=true), that I thought would be used magically by Spring Boot :
@Configuration
@EnableBatchProcessing(modular=true)
public class AppConfig {
@Bean
public ApplicationContextFactory addNewPodcastJobs(){
return new GenericApplicationContextFactory(AddPodcastJobConfiguration.class);
}
@Bean
public ApplicationContextFactory newEpisodesNotificationJobs(){
return new GenericApplicationContextFactory(NotifySubscribersJobConfiguration.class);
}
}
I will write a blog post about it when it is ready, but until then the code is available at https://github.com/podcastpedia/podcastpedia-batch (work/learning in progress)..