skip to content

What is MethodInvokingTaskletAdapter and when would you use it?

level: seniorimportance: should knowfreq 35%

answer

  1. Wraps an existing bean method as a Tasklet
  2. setTargetObject + setTargetMethod (String)
  3. Always returns FINISHED (no CONTINUABLE)
  4. Method's return -> ExitStatus
  5. Keeps domain code decoupled from Batch

basics

~20 s

It's an adapter that turns any existing Spring bean method into a Tasklet, so you don't have to implement the Tasklet interface. You set the target object and the method name, and its return value can drive exit status.

solid answer

~40 s

MethodInvokingTaskletAdapter (package org.springframework.batch.core.step.tasklet) lets you reuse an existing service method as a Tasklet without implementing the Tasklet interface. You configure it with a target object and a targetMethod name (and optionally arguments), and it invokes that method once per execute() call, always returning RepeatStatus.FINISHED. If the target method returns an ExitStatus, that becomes the step's exit status; if it returns any other non-null value, Spring derives an exit status from it. It's ideal when you already have a well-tested service — say, a reportService.generate() or a cleanup routine — and want to invoke it from a batch step with zero batch-specific coupling in your domain code. The trade-off: you can't return CONTINUABLE (it's always FINISHED) and you lose direct access to StepContribution/ChunkContext.

code

java · 7 lines
java
@Bean
MethodInvokingTaskletAdapter generateReportTasklet(ReportService reportService) {
    MethodInvokingTaskletAdapter adapter = new MethodInvokingTaskletAdapter();
    adapter.setTargetObject(reportService);
    adapter.setTargetMethod("generateDailyReport"); // returns ExitStatus or void
    return adapter;
}

go deeper

for a junior

May not know this adapter; enough to recognize it wraps a method as a Tasklet.

for a middle

Should configure targetObject/targetMethod and know it returns FINISHED.

for a senior

Should explain ExitStatus mapping, decoupling benefit, and CONTINUABLE limitation.

for a principal

Should weigh decoupling vs loss of framework hooks, and use SpEL late binding for parameterized invocation in a step-scoped design.

## Purpose `MethodInvokingTaskletAdapter` is a Spring-provided `Tasklet` implementation that **wraps an arbitrary method on any bean** so it can be used as a step's Tasklet — without your domain class knowing anything about Spring Batch. It builds on Spring's general `MethodInvokingBean` machinery. This keeps batch concerns out of business code: your `AccountService.reconcile()` stays a plain method; the adapter bridges it into a step. ## Configuration You set: - **`targetObject`** — the bean whose method to call. - **`targetMethod`** — the method name (as a String). - **`arguments`** (optional) — a fixed argument array passed to the method. ```java @Bean MethodInvokingTaskletAdapter reconcileTasklet(AccountService service) { MethodInvokingTaskletAdapter adapter = new MethodInvokingTaskletAdapter(); adapter.setTargetObject(service); adapter.setTargetMethod("reconcile"); return adapter; } @Bean Step reconcileStep(JobRepository repo, PlatformTransactionManager tx, MethodInvokingTaskletAdapter reconcileTasklet) { return new StepBuilder("reconcile", repo) .tasklet(reconcileTasklet, tx) .build(); } ``` ## Return value and ExitStatus The adapter always returns **`RepeatStatus.FINISHED`** from `execute()` — the method is called exactly once, so you **cannot** express CONTINUABLE looping. What the target method returns matters for exit status: - If it returns an **`ExitStatus`**, that value becomes the step's exit status directly. - If it returns any **other non-null** value, the adapter derives an `ExitStatus` code from it (via its string form) — useful for signalling a custom exit code that flow logic can branch on. - If it returns **void/null**, the step just completes normally (`ExitStatus.COMPLETED`). ## When to use it - You already have a **tested service method** and want to invoke it as a one-shot batch step. - You want to **avoid coupling** domain code to the `Tasklet` interface / Spring Batch types. - The work is a single call — no manual transactional looping needed. ## Limitations / gotchas - **No CONTINUABLE** — always FINISHED; not for chunked/looped work. - **No direct StepContribution/ChunkContext access** — the method signature is your own, so you can't easily read job parameters or update item counts from inside (you'd pass them as fixed `arguments`, or use late-binding SpEL to inject job parameters into the arguments). - **String method name** means refactors that rename the method won't be caught by the compiler. - Still runs inside the step's transaction like any Tasklet. ## Related adapters There are sibling adapters for the chunk world (`ItemReaderAdapter`, `ItemProcessorAdapter`, `ItemWriterAdapter`), but for Tasklets specifically, `MethodInvokingTaskletAdapter` is the one.

  • Can a MethodInvokingTaskletAdapter return RepeatStatus.CONTINUABLE?
    No. It invokes the target method once and always returns FINISHED. For looped/continuable work implement Tasklet directly or use the chunk model.
  • How does the target method's return value affect the step?
    If it returns an ExitStatus, that becomes the step's exit status; any other non-null return is converted (via its string form) into an ExitStatus code; void/null yields normal completion.
  • How do you pass job parameters into the invoked method?
    Set them via the adapter's arguments property, typically using late-binding SpEL like #{jobParameters['date']} on a step-scoped bean so the value is resolved at step execution time.

saying these in an interview costs you the question

  • Claiming the adapter can loop with CONTINUABLE
  • Thinking the target method receives StepContribution/ChunkContext automatically
  • Believing you must implement Tasklet to reuse a service method

context

resolving links…