javax.el.ELException: /dataset.xhtml #{DatasetPage.sizeOfDatasetOrig}: java.lang.NullPointerException #7663
Comments
|
Thanks @pdurbin, you beat me to it. @lmaylein, in the meantime, you should be able to resolve this by using the existing Redetect File Size endpoint described in the release notes here: https://github.com/IQSS/dataverse/blob/develop/doc/release-notes/7205-orig-file-size.md I'll close this, as we suspect this is fixed, but please let us know if there are any questions! |
|
I first tried it as described here: https://guides.dataverse.org/en/latest/api/native-api.html#datafile-integrity If I use the localhost address, I have to call CURL with the --insecure parameter (because the hostname of the certificate does not match). This is the corresponding api response: Surprisingly, the call works via the official domain name, which should not be the case according to the documentation: Even though I called this a few hours ago, this record is still not working: https://heidata.uni-heidelberg.de/dataset.xhtml?persistentId=doi:10.11588/data/10015 |
|
I'm reopening this issue because @lmaylein asked me to. It seems like the focus is now on how to use the Datafile Integrity API. |
|
I think that calling the API worked. But unfortunately that did not fix the problem. |
|
Okay. I found warnings in server.log that seem to come from the Datafile Integrity API. Unfortunately, it cannot be corrected in this way. |
This file definitely seems to be absent. If you go to https://heidata.uni-heidelberg.de/file.xhtml?fileId=205 and try to download the original SPSS binary, it fails. (This is one of the files in the dataset you linked above: https://heidata.uni-heidelberg.de/dataset.xhtml?persistentId=doi:10.11588/data/10015 ). |
|
This is, how it looks like in database and filesystem: This is one of our first data publications (using Dataverse 3.x). I wonder about the file names. With newer publications the file names in the file system consist of hash values. |
|
It seems that only datasets that already existed in version 3.x are affected. |
|
Thanks @lmaylein for the details, we'll need to take a deeper look. |
djbrooke
added this to Up Next 🛎
in IQSS/dataverse (TO BE RETIRED / DELETED in favor of project 34)
|
In addition: This is what the entry in dvobjects looks like. Is there anything else I could test? |
|
Is there anything else I can contribute? Is there any hope that the upgrade to version 5.4 will solve the problem? |
|
@lmaylein
|
|
@pdurbin Yes, that's right. The file is there. |
|
@pdurbin It is notable that the problem probably only occurs with tabular ingested files. |
|
A guess: In v4.x and 5.x original files are assumed to have the name of the original file appended with ".orig", e.g.: Do your orig files have a different naming convention coming from 3.x and therefore aren't being found? |
|
You can find the contents of the directory above (#7663 (comment)). The files were named this way by 3.x. A file named *.orig does not exist. |
|
Should I try to rename the files manually? If so, which file name should I choose? Does it have to be a hash value, as with newer datasets? |
|
The file names need to match whatever is in the database. No, it shouldn't need to be a hash value. |
|
@pdurbin: Thank you very much...
=> Download from https://heidata.uni-heidelberg.de/file.xhtml?fileId=205 works :-) And after calling the "Datafile Integrity" api Then I would now rename the other files manually. But what can I do in this case? How to rename 198.D03 and 198.D04? If necessary, I can find out which is the original file via the checksum. But what is hiding behind the other file? Can you explain me the old scheme of file names (from version 3.x)? |
|
@lmaylein great questions. I didn't have enough time in DVN 3.x to know the file naming conventions. I'll ask around a bit. |
actually, no, I don't think that's correct. It is the saved original of an ingested tabular file that used to be stored with the "_" prefix. I'm trying to remember when we made that change, and which release note the instructions would be in... |
|
OK, the change was made in v4.2.2: https://github.com/IQSS/dataverse/releases/tag/v4.2.2 From the "Post-deployment tasks" in the upgrade instruction, above: |
|
As for the remaining legacy files, the ones with the |
|
I had already suspected that I had overlooked an update step some time ago, but had only checked the first versions of 4.x. Many thanks for your help. |
Some of the datasets in our Dataverse installation (v5.3) cannot be accessed. The message is "Internal Server Error - An unexpected error was encountered, no more information is available."
Example: https://heidata.uni-heidelberg.de/dataset.xhtml?persistentId=doi:10.11588/data/10015
This error message can be found in server.log:
The text was updated successfully, but these errors were encountered: