Improvements to branch pds-api-125 #18
Comments
|
Quote @tloubrieu-jpl
Does that mean you want |
|
Hi @al-niessner , I noticed that when I ran your code on the previous repositories and the content of the pds4Product was the string you can see in screenshot
It should be decoded so that we can read the xml. I believe the code to decode the blob is there https://github.com/NASA-PDS/registry-api-service/blob/1258c795b24e3f09a826eb89bc3931bbd2441832/src/main/java/gov/nasa/pds/api/engineering/elasticsearch/entities/EntitytProductWithBlob.java#L21 |
|
It is weird though I can not reproduce that on you branch on this registry-api repository. I am getting a 500 error saying in log : |
|
I still have not worked through running locally. When I do I will resolve all the problems. Your pds-api-125 branch had 110 files changed. Since I changed less than 12, I discarded the branch with the 100 or so changes that I know nothing about. While it is clearer now what you mean by encoded pds4, but it is unclear what you want done about it. Decode it into something like XML or just remove it (all blobs were to be ignored previously). |
|
Sorry about the extra changes in the branch, I don't know what is was either. The 'ps:Label_File_Info/ops:blob' attribute in elasticsearch contains the PDS4 XML label compressed. We don't want to show it in that as compressed string to the user, but the actual XML. So it needs to be decoded before it is added to the response. The purpose of the mime type 'application/pds4+xml' is to show the original PDS4 XML label to the user. |
|
What curl command gave you the pds4 blob? |
|
Hi @al-niessner , This is the command I am using I've been able to reproduce it on the branch |
jordanpadams
changed the title
|
@tloubrieu-jpl |
|
Used your curl above and this is what I get (did not format it because it is so large anyway): Should I be using a different test data set? |
|
closed by mistake |
|
closed per #20 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
🐛 Describe the bug
At first sight, I am seeing 2 things to work on:
With this request:
curl --location --request GET 'http://localhost:8080/products'
--header 'Accept: application/xml'
There are multiple namespace prefixes which are redundant, see:
<wstxns1:q xmlns:wstxns1="http://pds.nasa.gov/api"/>
<wstxns2:hits xmlns:wstxns2="http://pds.nasa.gov/api">25</wstxns2:hits>
<wstxns3:took xmlns:wstxns3="http://pds.nasa.gov/api">956</wstxns3:took>
<wstxns4:start xmlns:wstxns4="http://pds.nasa.gov/api">0</wstxns4:start>
<wstxns5:limit xmlns:wstxns5="http://pds.nasa.gov/api">100</wstxns5:limit>
<wstxns6:sort xmlns:wstxns6="http://pds.nasa.gov/api"/>
<wstxns7:properties xmlns:wstxns7="http://pds.nasa.gov/api">
wstxns7:properties_package_id</wstxns7:properties>
wstxns7:propertiesdescription</wstxns7:properties>
wstxns7:propertiesinsight:Observation_Information.insight:mission_phase_name</wstxns7:properties>
They all (wstxns1, wstnx2, ...) have the same reference ("http://pds.nasa.gov/api") so we don't need multiple entries. I guess this is an effect of the marshalling library.
with request:
curl --location --request GET 'http://localhost:8080/products'
--header 'Accept: application/pds4+xml'
The pds4 xml is still encoded in the result.
The decoding function was in code in the past, maybe you can find it otherwise you can ask Eugene.
Test data / report
The text was updated successfully, but these errors were encountered: