"https://hdl.handle.net" is hard coded!

[Mahsanas]

Hi,

We are using handles for our dataverse instance and would like to use our local handle server instead of the Global Handle Registry (GHR). But the "https://hdl.handle.net" is hard coded at:
https://github.com/IQSS/dataverse/blob/v4.9.4/src/main/java/edu/harvard/iq/dataverse/HandlenetServiceBean.java#L396

Is it possible to make it configurable so we can use our local handle server instead of GHR ?

Thank you,

Mahsa
PS: for information on how local handle server can work as a resolution site (instead of GHR), please refer to chapter 10 of this document(http://www.handle.net/tech_manual/HN_Tech_Manual_9.pdf).

[pdurbin]

@Mahsanas with software, anything is possible. 😄

Are you interested in making a pull request? I would suggest adding a new JVM option similar to the ones described at http://guides.dataverse.org/en/4.9.4/installation/config.html#configuring-dataverse-for-handles . Perhaps it could be called "dataverse.handlenet.baseurlstring" to match "doi.baseurlstring"? In the code the variable is called "providerLink" so maybe that's a better name? I don't have a strong opinion about the name.

[poikilotherm]

Maybe this is related to #4106, too?

[PaulBoon]

It looks like you want an 'independent' server setup, is that true @Mahsanas?
The hardcoded "https://hdl.handle.net" has nothing to do with that, it just points to 'Handle' organisation and is not used to register.
At DANS we have the 'independent' setup working, but this needs a code change in the HandlenetServiceBean in order to work (see #5587).

BTW the handles should always resolve via handle.net, they use the prefix to find your handle server and redirect to the the landingpage registered at your server.

[pdurbin]

@PaulBoon I'd love to get you off a fork some day so if you feel like creating a pull request, please do! 😄

[PaulBoon]

I am getting closer towards a PR.
Also I have to admit that you can have handles not resolving via handle.net (GHR), but that would make them less persistent in my opinion. At DANS we wanted the independent setup just because of our strict firewall settings.

[pdurbin]

@PaulBoon thanks for working on this! Please let us know if you get blocked.

[PaulBoon]

I just rediscovered that the 'Independent handle service setup' does not work with the old client lib. This was one reason for us to upgrade with our fork more then a year ago.
Therefore I would like to do my PR for the setting based on the develop that has the upgraded 8.1.1. client lib in it (#4972). Would it be possible to have that one merged soon @pdurbin?

[pdurbin]

@PaulBoon well, there's a lot in QA right now. Please take a look at https://waffle.io/IQSS/dataverse . My suggestion would be to use your branch with a the new client lib as a starting point and create a new branch from there for this issue. Does that make sense? During code review we can always do "compare across branches" to see just the new "diff" but I'm not too worried about it because the "new client lib" pull request is fairly small and straightforward.

[PaulBoon]

After a bit of struggling with git rebase I managed to do a PR at #5604
Better squash all my commits when merging.

[djbrooke]

@Mahsanas I'm going to close this based on the discussion in #5604. If you feel this should still be open and if you still have this, please comment to let us know. Thanks!