Bump org.apache.commons:commons-configuration2 from 2.9.0 to 2.10.1

[dependabot]

Bumps org.apache.commons:commons-configuration2 from 2.9.0 to 2.10.1.

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[tdonohue]

@dependabot rebase

[tdonohue]

@dependabot rebase

[tdonohue]

@dependabot rebase

[tdonohue]

@abollini and @LucaGiamminonni : For some strange reason, this minor update to commons-configuration2 dependency causes every test in OrcidBulkPushIT to fail. I'm having difficulty understanding why, because we need to merge this minor change to solve security issues.

Could one of you find time to dig into this issue? It almost seems like a possible bug in either OrcidBulkPush or maybe in the ITs themselves to make them fail when an unrelated dependency is updated. For what it's work, I can reproduce this failure locally as well by simply updating commons-configuration2 and running:

mvn install -DskipIntegrationTests=false -Dit.test=OrcidBulkPushIT

[tdonohue]

@LucaGiamminonni and @abollini : I dug into this a bit more yesterday. I cannot get the OrcidBulkPushIT to succeed as soon as we upgrade commons-configuration2 to version 2.10.0 or above.

It seems like, after updating commons-configuration2, the OrcidBulkPush class is continually returning Errors occurs during ORCID object validation. Error codes: external-id.required for most every test that OrcidBulkPushIT runs.

I've had difficulty figuring out why these errors are occurring, but they are reproducible locally and in GitHub CI. If possible, I need help/support on fixing this. We need to find a way to safely upgrade commons-configuration2, but I don't want to break the OrcidBulkPush class in the process.

Assigning this PR to both of you, as I think you'll have an easier time that I on this. It's not obvious to me what the "external-id.required" error means or why it's being thrown in this scenario. It might be a sign of a bug in the code, or a broken IT. It's mysterious to me why upgrading commons-configuration2 causes this to appear, as that dependency doesn't seem to be used much by OrcidBulkPush.

[tdonohue]

@dependabot rebase

[tdonohue]

@abollini : After further investigation, I've determined that the failures in this PR appear to be a change in behavior for Apache Commons Configuration v2.

Specifically, the issue appears to be a problem loading an array of values out of a configuration file into a Spring Bean.

Let me explain:

1. As I noted before, the OrcidBulkPushIT tests are all throwing this error: Errors occurs during ORCID object validation. Error codes: external-id.required.
2. This error is caused because when turning the Item into an ORCID Work, the external identifiers (in this case the Item's Handle) are not mapped into the Work properly.
3. The reason appears to be that there's an array of configuration values for "external-ids" set here in orcid.cfg: https://github.com/DSpace/DSpace/blob/main/dspace/config/modules/orcid.cfg#L60-L65
4. This array of values is loaded into a Spring bean in orcid-services.xml here: https://github.com/DSpace/DSpace/blob/main/dspace/config/spring/api/orcid-services.xml#L56
5. Previously, this configuration worked fine, as the array of values was automatically turned into a comma-separated String.
6. However, after upgrading to commons-configuration2 version 2.10.1, only the first value in the array is saved to the Spring bean.

In other words, the only way I've found to fix the OrcidBulkPushIT errors is to move the $simple-handle::handle entry to be the first in the list of external-ids (because OrcidBulkPushIT only ever uses/defines the default handle). So, moving this setting to the top of the list causes all tests in OrcidBulkPushIT to pass:

orcid.mapping.work.external-ids = $simple-handle::handle

However, that implies to me that we have an issue with upgrading commons-configuration2. The array of values is no longer working properly with Spring...or the way that ORCID integrations attempt to use them no longer works. (I attempted a few minor refactors to see if I could get this working properly, but I've not been successful so far.)

SUMMARY: This upgrade to commons-configuration2 version 2.10.1 isn't compatible with DSpace at this time because of a change in behavior (or bug?) with changes between 2.9.0 -> 2.10.1.

However, I don't believe DSpace is vulnerable to the security issues fixed in commons-configuration2 version 2.10.1 because we do not use the affected AbstractListDelimiterHandler.flattenIterator() or ListDelimiterHandler.flatten(Object, int) methods.

[tdonohue]

To determine the source of the issue, I attempted a refactor to pull in multi-valued configurations via @Value annotations in OrcidWorkfFieldMapping like this:

@Value("${orcid.mapping.work.external-ids}")
public void setExternalIdentifierFields(String[] externalIdentifierFields) {

Unfortunately, that doesn't work either & only the first value is imported into the String[]. I believe this may be a bug in Apache Commons Configuration v2.10.0 and v2.10.1.

I've reported this issue on the PR which I believe may have caused this behavior change: apache/commons-configuration#309 (comment) Will move this report to the Apache Commons Configuration JIRA once I've been given permissions to do so.