An ItemProcessor, as defined by Java Batch contains only one method: processItem(Object item)
What I am missing are lifecycle events like open() and close() - similar to the methods on ItemReader or ItemWriter. I mimicked open() where processItem(item) will detect it is called for the first time and trigger a call to my open method.
But as close() is still missing I notice more complex ItemProcessors that need to cleanup after use have no chance of doing so. I tried to add the interface ChunkListener to benefit from the afterChunk() method, but at least in JBeret and BatchEE implementations that method is not called on a chunk's processor. It is the same for StepListener. Registering the ItemProcessor as Listener will just create another instance of the same class and cleanup will fail again.
Also I tried to use the finalize() method, but that seems not sufficient/reliable either.
If ItemProcessor is not intended to cleanup after use, how would I have to design the application such that complex decisions (which may require to connect to other systems like database) can be taken?
Jakarta Batch treats all batch artifacts as managed beans. CDI allows them to use events like
@PostConstruct
public void postConstruct() {
...
}
@PreDestroy
public void preDestroy() {
...
}
With them the necessary cleanup can be performed after use and before garbage collection kicks in.