TaskJobLauncherApplicationRunner overrides default job launcher behavior about spring-cloud-task HOT 8 CLOSED

Sure thing. The versions are as follows: Spring Cloud Task 2.4.3, Spring Batch 4.3.6, Spring Boot 2.7.1.

I also attach the sources of a test application. You can turn on/off the property "spring.cloud.task.batch.fail-on-job-failure" in application.yml, as needed.

Summing up, my concerns/questions are:

• TaskJobLauncherApplicationRunner is a subclass of JobLauncherApplicationRunner, but, in addition to exiting with code 1 when the batch fails, it "overrides" the default behavior altogether (calculating job parameters, monitoring job output, etc.). I don't really understand why two different runners are necessary, and if so, what is the difference between them.
• In case the only expected behavior is exiting with code 1, auto-configuring a default ExitCodeExceptionMapper with @ConditionalOnMissingBean should be enough, in line with the reference documentation of Spring Cloud Task.
• Indeed, I implemented such a thing in the attached test app (see code snippet below). This class propagates the batch exit status to task exit message, and returns a different exit code depending on the error type.
  NOTE: This configuration only works with the default JobLauncherApplicationRunner (fail-on-job-failure=false). For some reason, ApplicationEventPublisher is not autowired to TaskJobLauncherApplicationRunner and thus the application event listener is not called.

public final class BatchExitCodeExceptionMapper implements ApplicationListener<JobExecutionEvent>, ExitCodeExceptionMapper {
	
	private String exitMessage;
	
	@Override
	public void onApplicationEvent(JobExecutionEvent event) {	
		JobExecution execution = event.getJobExecution();
		
		exitMessage = execution.getExitStatus().getExitCode();
		
		if(execution.getStatus().equals(BatchStatus.FAILED)) {
			throw new JobFailedException(execution);
		}
	}
	
	@Override
	public int getExitCode(Throwable exception) {		
		Throwable cause = exception.getCause();

        	if (cause instanceof JobExecutionException) { // JobExecutionAlreadyRunningException, etc.        	
            		return ExitCodes.JOB_LAUNCH_FAILED.ordinal();            
        	} else if (cause instanceof JobFailedException) {         	
        		return ExitCodes.JOB_EXECUTION_FAILED.ordinal();        	
        	} else {        	
            		return ExitCodes.UNKNOWN_ERROR.ordinal();	
        	}
	}			
	
	@AfterTask
	public void onTaskEnd(TaskExecution taskExecution) {
		taskExecution.setExitMessage(exitMessage);		
	}	

	private enum ExitCodes {
		OK,
		JOB_EXECUTION_FAILED,
		JOB_LAUNCH_FAILED,		
		UNKNOWN_ERROR	
	}
}

test-app.zip

from spring-cloud-task.

Documentation needs to be updated. TaskJobLauncherApplicationRunner will be updated to match boot's job incrementer functionality.

from spring-cloud-task.

Could you provide the Spring Cloud Task, Spring Batch, and Spring Boot versions where this issue occurred?
Also can you provide a small sample app that exhibits the behavior?
Thank You!

from spring-cloud-task.

Most of the logic from TaskJobLauncherApplicationRunner.execute seems duplicated from JobLauncherApplicationRunner.execute. It's structured very differently but I think it's equivalent.

The problem seems to me that JobLauncherApplicationRunner does not have an extension point that would allow to use the logic in its private method getNextJobParameters and get access to the JobExecutions except through the JobExecutionEvents.

Maybe Spring Boot is willing to provide such an extension point. Then the duplicated code could be removed without re-building the logic around event listeners.

from spring-cloud-task.

@hpoettker You are correct in that it was created because there was no extension point with JobLauncherApplicationRunner. But as you discussed here and with your PR, I think we can approach the Boot team about adding it.

from spring-cloud-task.

For some reason, ApplicationEventPublisher is not autowired to TaskJobLauncherApplicationRunner and thus the application event listener is not called.

This is a separate issue. I've opened a PR for it: #889

from spring-cloud-task.

I've updated #888, which now uses the publishing of the JobExecutionEvents as extension point.

The new approach works because the default ApplicationEventMulticaster invokes all listeners synchronously. Therefore, the execution path is very similar to the current. It would stop working if e.g. a multi-threaded executor is used for invoking the listeners. But is this really a problem? An application that uses both the TaskJobLauncherApplicationRunner and a custom setup for handling ApplicationEvents seems unlikely to me.

from spring-cloud-task.

The root cause of this issue is resolved here: 4ea9b9f as it pertains to the JobExecutionEvent. As far as the duplicate it is being discussed on #888 .

from spring-cloud-task.