Permalink PIDs: UnmanagedPermaLinkProvider is not configured

[HenningTimm]

I am having some trouble setting up a Permalink pid provider on a newly installed Dataverse 6.5. When creating a new dataset using this pid provider, I am redirected to the draft dataset page, but Dataverse cannot find said page. Internally, Dataverse raises the following error

CommandException, when attempting to update the dataset: PID Provider UnmanagedPermaLinkProvider is not configured.

and no dataset is created. No new entries show up in the dataset table in the psql database.

What steps does it take to reproduce the issue?

Setup

I installed Dataverse using the Ansible Playbook — which configures a FAKE doi provider — and then manually configured an additional perma pid provider as follows:

# Default set during installation
-Ddataverse.pid.fake.type=FAKE
-Ddataverse.pid.fake.label=Fake DOI Provider
-Ddataverse.pid.fake.authority=10.5072
-Ddataverse.pid.fake.shoulder=FK2/

# My permalink provider
-Ddataverse.pid.perma1.type=perma
-Ddataverse.pid.perma1.label=PermaLink
-Ddataverse.pid.perma1.authority=abc1234
-Ddataverse.pid.perma1.permalink.separator=-
-Ddataverse.pid.perma1.shoulder=ds-
-Ddataverse.pid.perma1.permalink.identifier-generation-style=randomString
-Ddataverse.pid.perma1.permalink.base-url=https://dataverse.abc1234.uni-due.de/

# I overwrote these settings to make perma1 the default provider, but to offer both.
-Ddataverse.pid.providers=fake,perma1
-Ddataverse.pid.default-provider=perma1

Then I removed all PID-related settings via the /api/admin/settings API and restarted payara. Both providers show up in the user interface. Using the FAKE provider works, but when I switch to the perma provider I get the following error in server.log:

CommandException, when attempting to update the dataset: PID Provider UnmanagedPermaLinkProvider is not configured.
edu.harvard.iq.dataverse.engine.command.exception.IllegalCommandException: PID Provider UnmanagedPermaLinkProvider is not configured.
        at edu.harvard.iq.dataverse.engine.command.impl.CreateNewDatasetCommand.handlePid(CreateNewDatasetCommand.java:100)
        at edu.harvard.iq.dataverse.engine.command.impl.AbstractCreateDatasetCommand.execute(AbstractCreateDatasetCommand.java:134)
        at edu.harvard.iq.dataverse.engine.command.impl.AbstractCreateDatasetCommand.execute(AbstractCreateDatasetCommand.java:26)
        at edu.harvard.iq.dataverse.EjbDataverseEngineInner.submit(EjbDataverseEngineInner.java:36)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:569)
        at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:588)
        at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:408)
[...] 

Other approaches

I also tried a setup with only the permalink provider (without the fake doi provider). That setup had the same problem.

On an existing Dataverse 6.2 server, we have the following setup which works as expected:

-Ddataverse.pid.perma1.authority=foo
-Ddataverse.pid.perma1.permalink.separator=/
-Ddataverse.pid.perma1.shoulder=ds-

Mitigation

As suggested by Jim, I modified the shoulder and separator. I could not find a value for the shoulder that worked, but removing the shoulder altogether got the system running! I tried the following:

• "ds-" with separator "/": Yields the same error
• "ds/" with separator "/": Yields the same error
• "ds" with separator "/": Yields the same error
• No shoulder set with separator "/": Works!

Which version of Dataverse are you using?

• Dataverse 6.5
• Payara 6.2023.9

Any related open or closed issues to this bug report?

We faced problems with separators in permalink PIDs before. I am not sure if this is related, but just to be sure: #10564

This issue was also discussed in this zulip thread and on the mailing list.

[HenningTimm]

The settings that worked for me were as follows:

-Ddataverse.pid.fake.type=FAKE
-Ddataverse.pid.fake.label=Fake DOI Provider
-Ddataverse.pid.fake.authority=10.5072
-Ddataverse.pid.fake.shoulder=FK2/

-Ddataverse.pid.perma1.type=perma
-Ddataverse.pid.perma1.label=PermaLink
-Ddataverse.pid.perma1.authority=abc1234
-Ddataverse.pid.perma1.permalink.identifier-generation-style=randomString
-Ddataverse.pid.perma1.permalink.separator=/
-Ddataverse.pid.perma1.permalink.base-url=https://dataverse.abc1234.uni-due.de/citation?persistentId=perma:

-Ddataverse.pid.providers=fake,perma1
-Ddataverse.pid.default-provider=perma1

Though probably unrelated to this issue, I also had to explicitly set the permalink base url to include /citation?persistentId=perma: which was not necessary in Dataverse 6.2.

[qqmyers]

Thanks for the bug report! I’m glad you got something working. After confirming that parsing is working, I looked into how PIDs are generated and I think there's a bug when using a non-empty separator for Permalinks that will be fixed in #10790 (or - for now, non-default/non-empty separators aren't supported). Basically, a non-default separator is not being added to the newly created PID (but is being checked for in parsing). There is some fine logging in edu.harvard.iq.dataverse.pidproviders.AbstractPidProvider that should show this if anyone wants to look. I may suggest another unit test that can verify this going forward.

Details on checking the parsing:

In our tests we have a perma1 with - as a separator and QE as the shoulder and are able to parse DANSLINK-QE-5A-XN55
Locally I can change that to have the shoulder as ds- and it correctly parses perma:DANSLINK-ds-5A-XN55 .

Re: the base URL change:

The change to the base URL came in v 6.4 and is step 12 in the install instructions in the release note. It should not be involved in the error seen here though as it shouldn't be used when creating a dataset.

[qqmyers]

I should note the work-around too. Since separator and shoulder just get concatenated, a shoulder = -ds- with no separator would give you PIDs with the form you originally wanted. (As with DOIs, a perma separator is really just an administrative aid if you want to have multiple providers. Unlike DOIs, the fact that perma separators are configurable means you are responsible for assuring that multiple perma providers don't have overlapping ranges.)