-
Notifications
You must be signed in to change notification settings - Fork 490
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
File DOI registration with EZID does not make DOIs public #4828
Comments
@qqmyers thanks for making pull request #4830. I just moved this issue to code review at https://waffle.io/IQSS/dataverse |
@qqmyers I just remembered that by adding However, now there's a merge conflict with |
@qqmyers I see you resolved the merge conflict. Thanks! I assume you're ready for code review, but if not, please let us know! |
+1 - ready to go. |
That's great. I try not to change whitespace but was rushed with that commit. |
@qqmyers I see you moved those methods within the null check. Thanks. @sekmiller and I just talked about this issue and he'll take a look at your pull request. |
@qqmyers I've tested this and found that though it does not register unpublished files, it still registers published files as reserved rather than public |
@kcondon - Hmm - we just ran ezid publication of files on qdr and I verified that they were public. Our deployed code is more like the initial commits here, so perhaps something in the shuffle of code inside if statements broke it. I'm on travel, but will look again as I can to see if I can spot an issue. |
FWIW - the code at https://github.com/QualitativeDataRepository/dataverse/blob/v4.9.1-qdr-4777/src/main/java/edu/harvard/iq/dataverse/engine/command/impl/RegisterDvObjectCommand.java works for QDR. Other than moving the updates inside the test to see if an identifier exists, and merging with the change to use the GlobalIdServiceBean class, I don't see any difference that would cause it not to work with ezid... |
@qqmyers I think the branch you just mentioned is different from the one in the PR, no? |
@kcondon Yes. The URL in my comment is to QDR's current deployment. My point was that it works and I don't see anything different enough from the PR to cause what you're seeing. Unless you can see something, it would have to be something in the recent merge or some config issue, etc. The only guess I have would be that this change won't update existing reserved dois to public, so if some had been created before this patch, you'd still see them. |
OK, thanks. I've retested it and see the same "reserved" behavior. |
@kcondon - Thanks. What are you seeing in the log? For the original problem, there were warnings from EZID about the DOI already existing (because publicize calls create if the id isn't registered and create then fails.). With Fine logging, publicize adds a message but by default you should be seeing the warnings from within the create call. |
[2018-08-02T18:18:14.611-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.api.Admin] [tid: _ThreadID=35 _ThreadName=http-listener-1(5)] [timeMillis: 1533248294611] [levelValue: 800] [[ [2018-08-02T18:18:14.612-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.api.Admin] [tid: _ThreadID=35 _ThreadName=http-listener-1(5)] [timeMillis: 1533248294612] [levelValue: 800] [[ [2018-08-02T18:18:14.657-0400] [glassfish 4.1] [SEVERE] [] [edu.harvard.iq.dataverse.GlobalIdServiceBean] [tid: _ThreadID=35 _ThreadName=http-listener-1(5)] [timeMillis: 1533248294657] [levelValue: 1000] [[ [2018-08-02T18:18:14.709-0400] [glassfish 4.1] [SEVERE] [] [edu.harvard.iq.dataverse.GlobalIdServiceBean] [tid: _ThreadID=35 _ThreadName=http-listener-1(5)] [timeMillis: 1533248294709] [levelValue: 1000] [[ [2018-08-02T18:18:14.715-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.api.Admin] [tid: _ThreadID=35 _ThreadName=http-listener-1(5)] [timeMillis: 1533248294715] [levelValue: 800] [[ [2018-08-02T18:18:14.715-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.api.Admin] [tid: _ThreadID=35 _ThreadName=http-listener-1(5)] [timeMillis: 1533248294715] [levelValue: 800] [[ [2018-08-02T18:18:14.715-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.api.Admin] [tid: _ThreadID=35 _ThreadName=http-listener-1(5)] [timeMillis: 1533248294715] [levelValue: 800] [[ [2018-08-02T18:18:14.747-0400] [glassfish 4.1] [SEVERE] [] [edu.harvard.iq.dataverse.GlobalIdServiceBean] [tid: _ThreadID=35 _ThreadName=http-listener-1(5)] [timeMillis: 1533248294747] [levelValue: 1000] [[ [2018-08-02T18:18:14.781-0400] [glassfish 4.1] [SEVERE] [] [edu.harvard.iq.dataverse.GlobalIdServiceBean] [tid: _ThreadID=35 _ThreadName=http-listener-1(5)] [timeMillis: 1533248294781] [levelValue: 1000] [[ [2018-08-02T18:18:14.814-0400] [glassfish 4.1] [SEVERE] [] [edu.harvard.iq.dataverse.GlobalIdServiceBean] [tid: _ThreadID=35 _ThreadName=http-listener-1(5)] [timeMillis: 1533248294814] [levelValue: 1000] [[ [2018-08-02T18:18:14.821-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.api.Admin] [tid: _ThreadID=35 _ThreadName=http-listener-1(5)] [timeMillis: 1533248294821] [levelValue: 800] [[ [2018-08-02T18:18:14.821-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.api.Admin] [tid: _ThreadID=35 _ThreadName=http-listener-1(5)] [timeMillis: 1533248294821] [levelValue: 800] [[ [2018-08-02T18:18:14.821-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.api.Admin] [tid: _ThreadID=35 _ThreadName=http-listener-1(5)] [timeMillis: 1533248294821] [levelValue: 800] [[ [2018-08-02T18:18:14.821-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.api.Admin] [tid: _ThreadID=35 _ThreadName=http-listener-1(5)] [timeMillis: 1533248294821] [levelValue: 800] [[ [2018-08-02T18:18:14.822-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.api.Admin] [tid: _ThreadID=35 _ThreadName=http-listener-1(5)] [timeMillis: 1533248294822] [levelValue: 800] [[ [2018-08-02T18:18:14.822-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.api.Admin] [tid: _ThreadID=35 _ThreadName=http-listener-1(5)] [timeMillis: 1533248294822] [levelValue: 800] [[ [2018-08-02T18:18:14.822-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.api.Admin] [tid: _ThreadID=35 _ThreadName=http-listener-1(5)] [timeMillis: 1533248294822] [levelValue: 800] [[ [2018-08-02T18:18:14.822-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.api.Admin] [tid: _ThreadID=35 _ThreadName=http-listener-1(5)] [timeMillis: 1533248294822] [levelValue: 800] [[ |
@kcondon - OK - a good clue in the log: it looks like the protocol from the dvObject coming in is null and due to that, the new code in GlobalIdServiceBean is returning null instead of a bean - you've got the SEVERE log message about that. Any exception from that would get caught and ignored in the command class. Not sure I understand how you get reserved ids at all yet, but something to dig into now... |
@kcondon - When you said 'reserved' - did you just mean that the doi is in the DB or that you could see the DOI in EZID as 'reserved'?. Hopefully the former - I can see how the DOI would get generated before the null bean would cause an error and will add a fix in the PR, but if EZID is actually getting contacted, something else is going on. FWIW - this PR fixes the issue where EZID is contacted but the DOI is never transitioned from their 'reserved' to 'public' state. |
@qqmyers I could see the doi in EZID as reserved |
@kcondon - Hmm - I don't understand that unless some other part of the code sees the generated Id and calls EZID . Can you try the modification I just committed to the PR? It should allow the command to succeed and create IDs and make them public at EZID, and get rid of the SEVERE message in the logs. If it works, I can look a bit more and see if I can find if there is somewhere else EZID could be getting called to create but not publish/make public the DOI. |
@qqmyers your branch fails to build -refresh from /develop since we've fixed a failing test today |
@kcondon - its merged... |
@qqmyers Your last fixes have resolved the issue. I'll merge this now. Thanks! |
Yeah! So ftr the second commit handles a change between IdServiceBean and GlobalIdServiceBean where the latter no longer handles a null protocol parameter (by finding the currently configured one in the context) in the getBean() method. I did a quick search back through other places that call getBean() and I think all of the others handle situations where the protocol will always be defined. It's only for file during publication that their protocols will be null. |
Using the ezid test server, I was able to create file DOIs with the registerDataFileAll api call but the resulting DOIs are 'reserved' rather than 'public'. I was able to track this to the logic in RegisterDvObjectCommand which only does setIdentifierRegistered(true); after the call to publicizeIdentifier. For the DOIEZIdServiceBean, publicize tries to re-createIdentifier() if isIdentifierRegistered() is not true, which fails (identifier already exists). While EZID is on its way out, the problem would affect any registerWhenPublished() == false id provider.
I have a fix that I will post, but it may be a few days. In the meantime, I think going to 4.9.1 with EZID and running registerDataFileAll will leave identifiers in 'reserved' and throw error messages about duplicate ids in the log.
The text was updated successfully, but these errors were encountered: