OAI-PMH Remote Broken
Steps to reproduce
Steps to reproduce:
1. Try to publish or retract to/from OAI-PMH on a distributed cluster
Fails with 100% failure rate.
On the worker with the implementation:
2019-05-07T18:10:42,394 | WARN | (HttpChannel:579) - /publication/oaipmh org.eclipse.jetty.http.BadMessageException: 501: Unsupported Content-Encoding
2019-05-07T18:02:05,497 | ERROR | (WorkflowOperationWorker:180) - Workflow operation 'operation:'retract-oaipmh', position:2, state:'FAILED'' failed
org.opencastproject.publication.api.PublicationException: Unable to retract media package fc9ca451-e75b-4a49-81d7-224a2e550125 from OAI-PMH channel default using a remote publication service
at org.opencastproject.publication.oaipmh.remote.OaiPmhPublicationServiceRemoteImpl.retract(OaiPmhPublicationServiceRemoteImpl.java:217) [110:opencast-publication-service-oaipmh-remote:8.0.0.SNAPSHOT]
at org.opencastproject.workflow.handler.distribution.RetractOaiPmhWorkflowOperationHandler.start(RetractOaiPmhWorkflowOperationHandler.java:92) [74:opencast-distribution-workflowoperation:8.0.0.SNAPSHOT]
It seems that with different versions of Karaf respectively its implied dependency updates the behavior and strictness when encountering encoding schemes has changed (the code definitely used to work before).
Testing with opencast/develop, the line that causes the problem is:
whereas UTF_8 is of type CharSet (java.nio.charset.StandardCharsets.UTF_8).
The OAI-PMH remote is the only code in Opencast that uses setContentEncoding(). Without digging into further analysis, the toString() method of the Standard UTF-8 CharSet likely does not return "utf-8" but something similar. But as said, no digging further here as solution is to simply do the same as all other remotes which is known to work.
While I did not test whether 6.x is affected, I'm sure this won't break anything and therefore "fix" this in 6.x.