Я решил эту проблему для себя, хотя я удивлен тем, что мне пришлось сделать.Отлаживая через StaxEventItemReader, я заметил, что внутренний цикл в методе moveCursorToNextFragment () станет бесконечным, когда будет достигнут конец моего документа.Вот соответствующий код:
while (true) {
while (reader.peek() != null && !reader.peek().isStartElement()) {
reader.nextEvent();
}
if (reader.peek() == null) {
return false;
}
QName startElementName = ((StartElement) reader.peek()).getName();
if (startElementName.getLocalPart().equals(fragmentRootElementName)) {
if (fragmentRootElementNameSpace == null
|| startElementName.getNamespaceURI().equals(fragmentRootElementNameSpace)) {
return true;
}
}
reader.nextEvent();
}
reader.peek () никогда не возвращал ноль.Мне показалось, что этот код должен проверять, находится ли XMLEvent, обнаруженный во время peek (), в конце документа, но это было не так просто из-за зависимости StaxEventItemReader от DefaultFragmentEventReader, обертывающего стандартный XMLEventReader.
В итоге я развернул свой собственный ItemReader, основанный на StaxEventItemReader, но без использования FragmentEventReader, а затем настроил код внутреннего цикла так, чтобы он читался так:
if (reader.peek().getEventType() == XMLStreamConstants.END_DOCUMENT) {
return false;
}
reader.nextEvent();
Это прекрасно работает ипозволяет моей пакетной работе перейти в ЗАВЕРШЕНО в конце ввода.
Я действительно удивлен тем, что мне пришлось это сделать.Мне было интересно, виновата ли базовая реализация потоковых XML-библиотек, которые я использовал, но я использую stax2-api-3.0.1.jar, как указано в списке зависимостей Spring Batch.
Я также нашелчто я не одинок .