Replies: 1 comment
-
|
This seems like more of an idea for the Jakarta Batch specification itself. Have you tried reaching out to them? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I believe there are only a few components that have an acceptable lifecycle. Why is that a problem?
In my setup I am trying to reuse Reader/Writer implementations as much as possible - but that means they are quite generic. What changes between batch jobs most times are ItemProcessors and listeners. This involves that some ItemProcessors need to take complex decisions, maybe even looking up stuff in other backend systems (e.g. database). Consider the processor as heavy enough it needs to cleanup when it is no longer required. And there can be lots of instances of such processors. We are running partitioned jobs with parallel execution, so proper cleanup is really important.
Unfortunately Java Batch only demands an ItemProcessor to have one method: processItem
I am missing some open/close methods. And thinking further it would not be wise to change the API and with that the specification -it would just not be compatible any more. So I have a different idea:
What if an ItemProcessor also implements some listener interface? That could be a StepListener or a PartitionListener. JBeret could register that processor amongst the other listeners so it gets informed on the lifecycle. The same could be done for the other components like reader, writer, batchlet, ...
No API change, no new classes. Just reuse what exists already, and the change would be fairly slim but with great effect.
What do others think about this?
Beta Was this translation helpful? Give feedback.
All reactions