Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

StaxEventItemWriter.unclosedHeaderCallbackElements prevents new job execution #4044

Closed
Alex4i opened this issue Jan 6, 2022 · 1 comment
Closed
Labels
for: backport-to-4.3.x Issues that will be back-ported to the 4.3.x line has: minimal-example Bug reports that provide a minimal complete reproducible example in: core type: bug
Milestone

Comments

@Alex4i
Copy link

Alex4i commented Jan 6, 2022

While upgrading to spring-batch 4.3.4, my job started to fail with the exception :
The class with javax.xml.namespace.QName and name of javax.xml.namespace.QName is not trusted.

After investigating, it turns out that StaxEventItemWriter (with saveState=true) writes unclosed elements from the header callback to the step context as QNames. On the next job execution, it will first try to read the last job execution and this is where the exception appears as the step execution from StaxEventItemWriter cannot be deserialized.

This was not a problem before 4.3.4 as SimpleJobExplorer#getLastJobExecution did not fetch step executions (see #3943) but now that it does, it means that StaxEventItemWriter is not usable with a header callback out-of-the-box. EIther we have to set saveState=false on the writer, or we must create a BatchConfigurer to add the mixIn for QName to the ObjectMapper.

I think that at the very least, documentation should reflect this.

Minimal example : https://github.com/Alex4i/staxwriter_qname
Run with gradlew bootRun

@Alex4i Alex4i added status: waiting-for-triage Issues that we did not analyse yet type: bug labels Jan 6, 2022
@cppwfs cppwfs removed the status: waiting-for-triage Issues that we did not analyse yet label Feb 1, 2022
@fmbenhassine fmbenhassine added the has: minimal-example Bug reports that provide a minimal complete reproducible example label Apr 27, 2022
@fmbenhassine
Copy link
Contributor

Thank you for opening this issue and for providing a minimal complete example! Indeed, the sample fails with the default configuration of the serializer. Using a custom serializer that trusts javax.xml.namespace.QName makes your sample work without any issue. According to Jackson's type validator, this class is safe to deserialize. Hence, I see no harm in adding it to the default list of trusted classes in Spring Batch (in order to avoid the effort of providing a custom serializer).

@fmbenhassine fmbenhassine added this to the 5.0.0-M3 milestone May 17, 2022
@fmbenhassine fmbenhassine added the for: backport-to-4.3.x Issues that will be back-ported to the 4.3.x line label May 17, 2022
fmbenhassine added a commit that referenced this issue May 17, 2022
This class is safe to deserialize according to Jackson:
https://github.com/FasterXML/jackson-databind/blob/master/src/main/java/com/fasterxml/jackson/databind/jsontype/impl/SubTypeValidator.java

This also has been checked against Jackson 2.11 to confirm
the backport of this enhancement to 4.3.x.

Resolves #4044
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: backport-to-4.3.x Issues that will be back-ported to the 4.3.x line has: minimal-example Bug reports that provide a minimal complete reproducible example in: core type: bug
Projects
None yet
Development

No branches or pull requests

3 participants