(It seems like the question re: afterStep has been settled).
Comment from = ScottKurz on 2015-10-08 16:18:53 +0000
Maybe also just clarify that onError is NOT called in either of a skipped or no-rollback exception. I think the outline and Javadoc together already implies this though.
Comment from = ScottKurz on 2015-10-19 20:23:43 +0000
Note that the java.net link above is bad, but we had it archived...pasting it here
From Mario Koedding 8 December 2014
Hi,
in one of my projects, we are using JBatch/JSR352 for implementing batch
jobs. We have some integration-tests running on WildFly 8.1 as well as
Glassfish 4.
Resulting from this setup, we discovered some differences in the behavior of
JBeret and the JBatch RI included in Glassfish (and also its fork, Apache
BatchEE) concerning listeners in case of exceptions. So currently, our batch
jobs behave differently / produce different results, depending on the JSR352
implementation of the underlying JEE container, which is quite annoying. I
have already discussed this topic with Cheng Fang on the JBeret issue tracker:
Here's a short summary of the discovered differences:
If there is an exception thrown inside the open() and close() methods of
an ItemReader/ItemWriter, then JBeret will not call the onError() method of
the defined ChunkListeners, while JBatch RI / Apache BatchEE do call the
method.
In the discussion linked above, we have agreed that JBeret behaves correctly
according to the spec, as the open() and close() methods are not really part
of the actual chunks and thus, it does not make sense to call the
chunk-listener there (I will open a ticket for BatchEE for that. And is there
also an issue tracker for the original JBatch RI?)
If there is an exception thrown at any point inside a Chunk-step or
Batchlet-step, then JBeret will not call the afterStep() method of the
defined StepListeners, while JBatch RI / Apache BatchEE do call the method.
The interface-documentation for the afterStep() method says "The afterStep
method receives control after a step execution ends.", which does not
explicitly mention the exception-case. But following the logic of
ChunkListener.afterChunk(), the afterStep() method should not be called in
case of exceptions. So from my point of view, JBeret's behavior is correct
here and JBatch RI / BatchEE would have to adjust their implementation (I
will include this in the ticket).
However, if the behavior of JBeret is correct according to the spec in both
cases, currently I don't see any possibility to implement some top-level
exception-processing / generic error-handling in form of a listener. Our use
case here is to do some logging / create an error-protocol for all
exceptions, which occur during the job run, including those inside of the
open() and close() methods of Readers/Writers and inside Batchlet-steps.
Currently, the only possibility I see to implement this cross-cutting
functionality is to implement our own exception-handling inside the
corresponding open() and close() methods (catch, log, re-throw), which is not
as generic as we would like it to be. Any other suggestions are appreciated,
of course :)
From my point of view, a possibility for top-level error-handling would be
great (e.g. in form of a StepListener.onError() method). This would cover
exceptions during Batchlet-processing as well as exceptions inside
chunk-steps, which occur outside of the single chunks (e.g. in the open() and
close() methods). What do you think about that?
Originally opened as bug 6587 by ScottKurz
--------------Original Comment History---------------------------- Comment from = ScottKurz on 2014-12-16 20:13:00 +0000
See
https://java.net/projects/jbatch/lists/public/archive/2014-12/message/3
(It seems like the question re: afterStep has been settled).
Comment from = ScottKurz on 2015-10-08 16:18:53 +0000
Maybe also just clarify that onError is NOT called in either of a skipped or no-rollback exception. I think the outline and Javadoc together already implies this though.
Comment from = ScottKurz on 2015-10-19 20:23:43 +0000
See also Bug 7350.
Bug 7350 is now https://github.com/eclipse-ee4j/batch-api/issues/88
Note that the java.net link above is bad, but we had it archived...pasting it here
From Mario Koedding 8 December 2014
Hi,
in one of my projects, we are using JBatch/JSR352 for implementing batch jobs. We have some integration-tests running on WildFly 8.1 as well as Glassfish 4.
Resulting from this setup, we discovered some differences in the behavior of JBeret and the JBatch RI included in Glassfish (and also its fork, Apache BatchEE) concerning listeners in case of exceptions. So currently, our batch jobs behave differently / produce different results, depending on the JSR352 implementation of the underlying JEE container, which is quite annoying. I have already discussed this topic with Cheng Fang on the JBeret issue tracker:
https://github.com/jberet/jsr352/issues/25
Here's a short summary of the discovered differences:
In the discussion linked above, we have agreed that JBeret behaves correctly according to the spec, as the open() and close() methods are not really part of the actual chunks and thus, it does not make sense to call the chunk-listener there (I will open a ticket for BatchEE for that. And is there also an issue tracker for the original JBatch RI?)
The interface-documentation for the afterStep() method says "The afterStep method receives control after a step execution ends.", which does not explicitly mention the exception-case. But following the logic of ChunkListener.afterChunk(), the afterStep() method should not be called in case of exceptions. So from my point of view, JBeret's behavior is correct here and JBatch RI / BatchEE would have to adjust their implementation (I will include this in the ticket).
However, if the behavior of JBeret is correct according to the spec in both cases, currently I don't see any possibility to implement some top-level exception-processing / generic error-handling in form of a listener. Our use case here is to do some logging / create an error-protocol for all exceptions, which occur during the job run, including those inside of the open() and close() methods of Readers/Writers and inside Batchlet-steps.
Currently, the only possibility I see to implement this cross-cutting functionality is to implement our own exception-handling inside the corresponding open() and close() methods (catch, log, re-throw), which is not as generic as we would like it to be. Any other suggestions are appreciated, of course :)
From my point of view, a possibility for top-level error-handling would be great (e.g. in form of a StepListener.onError() method). This would cover exceptions during Batchlet-processing as well as exceptions inside chunk-steps, which occur outside of the single chunks (e.g. in the open() and close() methods). What do you think about that?
Best regards
Mario Ködding