pds-api-125: get the XML MIME types working again #20

al-niessner · 2022-01-05T18:57:13Z

🗒️ Summary

Reworked the XML serialization.

⚙️ Test Data and/or Report

$ curl --location --request GET 'http://localhost:8080/products/urn:nasa:pds:izenberg_pdart14_meap:document:ns_inst::1.0' --header 'Accept: application/xml'
<PdsProduct xmlns="http://pds.nasa.gov/api"><id>urn:nasa:pds:izenberg_pdart14_meap:document:ns_inst::1.0</id><type>Product_Document</type><title>MESSENGER Neutron Spectrometer (NS) Description</title><description/><start_date_time/><stop_date_time/><investigations><investigations><title/><id>urn:nasa:pds:context:investigation:mission.messenger</id><href>http://localhost:8080/products/urn:nasa:pds:context:investigation:mission.messenger</href><type/><description/></investigations></investigations><observing_system_components><observing_system_components><title/><id>urn:nasa:pds:context:instrument_host:spacecraft.mess</id><href>http://localhost:8080/products/urn:nasa:pds:context:instrument_host:spacecraft.mess</href><type/><description/></observing_system_components><observing_system_components><title/><id>urn:nasa:pds:context:instrument:ns.mess</id><href>http://localhost:8080/products/urn:nasa:pds:context:instrument:ns.mess</href><type/><description/></observing_system_components></observing_system_components><targets><targets><title/><id>urn:nasa:pds:context:target:planet.mercury</id><href>http://localhost:8080/products/urn:nasa:pds:context:target:planet.mercury</href><type/><description/></targets></targets><metadata xmlns=""><creation_date_time xmlns="http://pds.nasa.gov/api"/><update_date_time xmlns="http://pds.nasa.gov/api"/><version xmlns="http://pds.nasa.gov/api">1.0</version><label_url xmlns="http://pds.nasa.gov/api">/var/local/harvest/archive/document/ns_inst.xml</label_url></metadata><properties/></PdsProduct>


$ curl --location --request GET 'http://localhost:8080/products/urn:nasa:pds:izenberg_pdart14_meap:document:ns_inst::1.0' --header 'Accept: application/pds4+xml'
<Pds4Product><id>urn:nasa:pds:izenberg_pdart14_meap:document:ns_inst::1.0</id><metadata><node_name>PSA</node_name><label_file><file_name>ns_inst.xml</file_name><file_ref>/var/local/harvest/archive/document/ns_inst.xml</file_ref><creation_date>2021-05-12T18:17:17Z</creation_date><file_size>3589</file_size><md5_checksum>a8d09cca0a01728db50c15052c2736cf</md5_checksum></label_file><data_files><data_files><file_name>ns_inst.pdf</file_name><file_ref>/var/local/harvest/archive/document/ns_inst.pdf</file_ref><creation_date>2021-05-12T18:17:17Z</creation_date><file_size>138172</file_size><md5_checksum>8103f20c13a3c321dac4a193aba19d16</md5_checksum><mime_type>application/pdf</mime_type></data_files></data_files></metadata><pds4/></Pds4Product>

♻️ Related Issues

#456
#440
NASA-PDS/pds-api#18
NASA-PDS/pds-api#73

Generated a patch from NASA-PDS/registry-api-service branch pds-api-125 of the code changes along the branch thus far. The file locations in the new repository have changed so used emacs to replace all /src/main/ with /api/src/main/. With a functional patch, used git to apply it in this repository to create the branch pds-api-125.

al-niessner · 2022-01-12T18:57:05Z

@tloubrieu-jpl @jordanpadams

Something is still wrong with this repo and my permissions. If I do the git fetch and git merge for main, it says up to date. However this PR seems to think there are conflicts but it seems to be more about my permissions to not write or merge to main via the PR than actual conflicts.

tloubrieu-jpl · 2022-01-12T19:13:57Z

Hi @al-niessner ,

Di you also make git pull origin main to make sure you have the same main in your local repo as in the remote repository ?

al-niessner · 2022-01-12T19:43:06Z

@tloubrieu-jpl

Yup, that worked and nothing in eclipse works again. Another day lost.

service/src/main/java/gov/nasa/pds/api/engineering/serializer/PdsProductXMLSerializer.java

service/src/main/java/gov/nasa/pds/api/engineering/serializer/PdsProductsXMLSerializer.java

service/src/main/java/gov/nasa/pds/api/engineering/serializer/Pds4XmlProductSerializer.java

service/src/main/java/gov/nasa/pds/api/engineering/serializer/PdsProductXMLSerializer.java

service/src/main/java/gov/nasa/pds/api/engineering/serializer/PdsProductsXMLSerializer.java

al-niessner · 2022-01-12T20:37:54Z

@tloubrieu-jpl @jordanpadams

Okay, back to where I was. At least it was quicker. Failing to map pds4+xml again. Thought it would be a problem with the model (previously known as pds-api-javalib) as in the past so I upped the version in model/pom.xml to 0.5.1-SNAPSHOT and then made services/pom.xml match:

$ git diff
diff --git a/model/pom.xml b/model/pom.xml
index b43e47f..21237f2 100644
--- a/model/pom.xml
+++ b/model/pom.xml
@@ -34,7 +34,7 @@
   <modelVersion>4.0.0</modelVersion>
   <groupId>gov.nasa.pds</groupId>
   <artifactId>registry-api-model</artifactId>
-  <version>0.5.0-SNAPSHOT</version>
+  <version>0.5.1-SNAPSHOT</version>
   <name>${project.groupId}:${project.artifactId}</name>
   <description>PDS Registry API Controllers and Reponses Models</description>
   <properties>
diff --git a/service/pom.xml b/service/pom.xml
index 60c0c04..4543c2c 100644
--- a/service/pom.xml
+++ b/service/pom.xml
@@ -260,7 +260,7 @@ POSSIBILITY OF SUCH DAMAGE.
                <dependency>
                        <groupId>gov.nasa.pds</groupId>
                        <artifactId>api</artifactId>
-                        <version>0.5.0-SNAPSHOT</version>
+                        <version>0.5.1-SNAPSHOT</version>
                </dependency>
 
                <dependency>

I thought that since I was doing 'mvn clean install' at registry-api repo root that it would use the fresh build. Instead I am seeing this:

[ERROR] Failed to execute goal on project registry-api-service: Could not resolve dependencies for project gov.nasa.pds:registry-api-service:jar:0.5.0-SNAPSHOT: Could not find artifact gov.nasa.pds:api:jar:0.5.1-SNAPSHOT in oss.sonatype.org-snapshot (https://oss.sonatype.org/content/repositories/snapshots) -> [Help 1]

What is/was the idea for building all these items as one consistent set?

al-niessner · 2022-01-12T21:42:49Z

@tloubrieu-jpl @jordanpadams

Tried doing 'mvn clean install' in the registry-api/model directory followed by same command in registry-api and have same failure. Interestingly it builds the correct artifacts and installs them, I presume locally, but then does not use them:

[INFO] gov.nasa.pds:registry-api-model 0.5.1-SNAPSHOT ..... SUCCESS [  5.768 s]
[INFO] PDS API Search Query Lexer 1.1.0-SNAPSHOT .......... SUCCESS [02:31 min]
[INFO] gov.nasa.pds.api.registry-service 0.5.0-SNAPSHOT ... FAILURE [03:43 min]
[INFO] gov.nasa.pds:registry 0.5.0-SNAPSHOT ............... SKIPPED
<...snip...>
[ERROR] Failed to execute goal on project registry-api-service: Could not resolve dependencies for project gov.nasa.pds:registry-api-service:jar:0.5.0-SNAPSHOT: Could not find artifact gov.nasa.pds:api:jar:0.5.1-SNAPSHOT in oss.sonatype.org-snapshot (https://oss.sonatype.org/content/repositories/snapshots) -> [Help 1]

tloubrieu-jpl · 2022-01-12T21:48:45Z

Hi @al-niessner sorry about these issues. I will try to reproduce that tomorrow in the morning.

al-niessner · 2022-01-12T22:16:48Z

Hi @al-niessner sorry about these issues. I will try to reproduce that tomorrow in the morning.

@tloubrieu-jpl Thanks, but I think I have it. Just catching some of the looser ends.

To have an independent build, the artifacts in service pom have to match those in the other directories: lexer and model. Once all the artifacts were referenced correctly, the build is independent of what is deployed at the maven archives so that what is developed is consistent.

sonatype-lift · 2022-01-12T23:18:14Z

service/pom.xml

-			<artifactId>api</artifactId>
-			<version>0.5.0-SNAPSHOT</version>
+			<artifactId>registry-api-model</artifactId>
+                        <version>0.5.0-SNAPSHOT</version>
 		</dependency>

 		<dependency>


Critical OSS Vulnerability:

pkg:maven/gov.nasa.pds/[email protected]

4 Critical, 0 Severe, 2 Moderate, 0 Unknown vulnerabilities have been found across 2 dependencies

Components

pkg:maven/log4j/[email protected]

CRITICAL Vulnerabilities (2)

CVE-2019-17571

[CVE-2019-17571] Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserializat...

Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. This affects Log4j versions up to 1.2 up to 1.2.17.

CVSS Score: 9.8

CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

CVE-2021-4104

[CVE-2021-4104] JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when...

JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.

===================================================
The following information is provided by Sonatype Nexus Intelligence. Nexus Intelligence is the only security research service that performs "secondary expansion" to determine if newly discovered vulnerabilities are also present in other components.

Learn more about Nexus Intelligence -- https://www.sonatype.com/products/intelligence

Explanation

The log4j:log4j package is vulnerable to Deserialization of Untrusted Data. The lookup() and activateOptions() methods in the JMSAppender class allow JNDI lookup requests to be made when the TopicBindingName and TopicConnectionFactoryBindingName specify a trusted host. Lookups made to this host may be used by attackers to request a serialized malicious Java Object that can be deserialized and executed, leading to Remote Code Execution (RCE).

Note that this vulnerability is different from CVE-2021-44228 and requires the attacker to be in control of the third party host that is specified in the configuration, or write access to the Log4j configuration file in order to specify a malicious lookup host directly. This vulnerability also only affects the 1.x.x component of Log4j released under the log4j:log4j group and artifact IDs.

Advisory Deviation Notice: The Sonatype security research team discovered that the root cause of the vulnerability is in all versions of log4j:log4j, not just in the 1.2.x branch as the advisory states.

Detection

The application is vulnerable by using this component under the following circumstances:

The configuration file specifies an allowed third-party JNDI lookup host for the JMSAppender

the javax.jms.* API is included in the application's CLASSPATH

Reference: https://bugzilla.redhat.com/show_bug.cgi?id=2031667#c28

Recommendation

The 1.x.x component has reach End of Life, and users should upgrade to a non-vulnerable version of org.apache.logging.log4j:log4j-core as this component includes other security vulnerabilities that are not fixed.

References:

Restrict LDAP access via JNDI apache/logging-log4j2#608 (comment)

https://logging.apache.org/log4j/1.2/

CVSS Score: 8.1

CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

MODERATE Vulnerabilities (1)

[CVE-2020-9488] Improper validation of certificate with host mismatch in Apache Log4j SMTP appen...

Improper validation of certificate with host mismatch in Apache Log4j SMTP appender. This could allow an SMTPS connection to be intercepted by a man-in-the-middle attack which could leak any log messages sent through that appender.

CVSS Score: 3.7

CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

pkg:maven/log4j/[email protected]

CRITICAL Vulnerabilities (2)

CVE-2019-17571

[CVE-2019-17571] Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserializat...

Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. This affects Log4j versions up to 1.2 up to 1.2.17.

CVSS Score: 9.8

CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

CVE-2021-4104

[CVE-2021-4104] JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when...

JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.

===================================================
The following information is provided by Sonatype Nexus Intelligence. Nexus Intelligence is the only security research service that performs "secondary expansion" to determine if newly discovered vulnerabilities are also present in other components.

Learn more about Nexus Intelligence -- https://www.sonatype.com/products/intelligence

Explanation

The log4j:log4j package is vulnerable to Deserialization of Untrusted Data. The lookup() and activateOptions() methods in the JMSAppender class allow JNDI lookup requests to be made when the TopicBindingName and TopicConnectionFactoryBindingName specify a trusted host. Lookups made to this host may be used by attackers to request a serialized malicious Java Object that can be deserialized and executed, leading to Remote Code Execution (RCE).

Note that this vulnerability is different from CVE-2021-44228 and requires the attacker to be in control of the third party host that is specified in the configuration, or write access to the Log4j configuration file in order to specify a malicious lookup host directly. This vulnerability also only affects the 1.x.x component of Log4j released under the log4j:log4j group and artifact IDs.

Advisory Deviation Notice: The Sonatype security research team discovered that the root cause of the vulnerability is in all versions of log4j:log4j, not just in the 1.2.x branch as the advisory states.

Detection

The application is vulnerable by using this component under the following circumstances:

The configuration file specifies an allowed third-party JNDI lookup host for the JMSAppender

the javax.jms.* API is included in the application's CLASSPATH

Reference: https://bugzilla.redhat.com/show_bug.cgi?id=2031667#c28

Recommendation

The 1.x.x component has reach End of Life, and users should upgrade to a non-vulnerable version of org.apache.logging.log4j:log4j-core as this component includes other security vulnerabilities that are not fixed.

References:

Restrict LDAP access via JNDI apache/logging-log4j2#608 (comment)

https://logging.apache.org/log4j/1.2/

CVSS Score: 8.1

CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

MODERATE Vulnerabilities (1)

[CVE-2020-9488] Improper validation of certificate with host mismatch in Apache Log4j SMTP appen...

Improper validation of certificate with host mismatch in Apache Log4j SMTP appender. This could allow an SMTPS connection to be intercepted by a man-in-the-middle attack which could leak any log messages sent through that appender.

CVSS Score: 3.7

CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

(at-me [in a reply](https://help.sonatype.com/lift/talking-to-lift) with `help` or `ignore`)

tloubrieu-jpl · 2022-01-13T19:20:00Z

Hi @al-niessner , thanks for solving that. I tried anyway this morning to have a 'stable' method to import.

So I did in eclipse:

import git (smart import)
convert to maven
add manually the lexer and model jar dependency in the service build path

And I think I have all errors removed. I will write that in the README.

al-niessner · 2022-01-19T17:25:03Z

@tloubrieu-jpl @jordanpadams

Reviewing this data again because it has been bugging me what PDS-4 blob needs to be decoded when it seems none are found in my searches. It seems from reviewing NASA-PDS/pds-api#18 that @jordanpadams is not getting his wish about never seeing ops:Label_File_Info/ops:blob ever again is not really true. It seems the request has been to decode ops:Label_File_Info/ops:blob and put it in <pds4> in the output. Is that what all the PDS-4 decode comments have been circling?

jordanpadams · 2022-01-19T19:38:45Z

@al-niessner those comments were a bit dated, but basically, I don't want to ever see ops:Label_File_Info/ops:blob, but if it is decoded to the actual metadata, now we have something that is reasonable parseable and usable.

per the blob not being found in your searches, not sure. i don't have this deployed locally so I cannot reproduce. at least from the version on pds-gamma, I do see the json_blob for the JSON response

al-niessner · 2022-01-19T20:37:23Z

@jordanpadams @tloubrieu-jpl

Should ops:Label_File_Info/ops:blob always be decoded -- as in KVP+JSON as well as JSON as well as PDS4+* -- or just in limited situations? If limited situations, then specifically which? It is probably simpler (code and then maintain) to decode in all output types than to limit it to specific output types.

jordanpadams · 2022-01-19T20:45:27Z

@al-niessner I am fairly certain the blob should only be decoded for pds4+json and pds4+xml. those are the only times when we want to output everything in the metadata label. In all other instances, there is some customized/flattened response being returned

jordanpadams · 2022-01-19T20:46:10Z

for the remaining response types, blob and json_blob should be hidden from the API response

Turns out there is a lot of duplicate code that wanted to do the same thing but had different behaviors and end results. This really made testing and comparing odd because it would fail for one user but not another mostly because of endpoints used when there should have been no difference. This change cleans most of that up with respect to getting data and using the fields to include and those to exclude. The blob has successfully been removed once again.

First, there are now two blob possibilities and they are encoded. Added the second blob type and adjusted the searching to handle either or both or neither. The Pds4Prduct JSON serializer did the decoding of the blob. Moved it from the single serializer to the Pds4ProductFactory where all of the creation happens. Now the blob is decoded for PDS4 only but for any PDS4 output format.

al-niessner · 2022-01-24T22:30:21Z

@tloubrieu-jpl @jordanpadams

All four issues at the top of this PR are now fixed. PDS4 outputs for JSON and XML both return the decoded JSON block now. Both blobs are now being filtered out by default but if explicitly specified will show up encoded in any other output structure. All XML output work as well.

tloubrieu-jpl

Hi @al-niessner ,

Thanks for the update.

When I do the following request:

curl --location --request A 'http://localhost:8080/products' \
--header 'Accept: application/json'

I am getting this error:

{
    "timestamp": 1643069228942,
    "status": 405,
    "error": "Method Not Allowed",
    "message": "",
    "path": "/products"
}

The request

curl --location --request GET 'http://localhost:8080/bundles' \
--header 'Accept: application/kvp+json'

and same with 'text/csv'

Give 500 error (I think that is only when fields is not specified)

I did not have that before.

Regarding the application/pds4+xml output, there is no xml namespace definition available starting from tag Pds4Product. Do you know why it is ?

At last, the decoded part of the XML label looks weird (more json than xml):

<pds4>{"Product_Observational":{"Identification_Area":{"product_class":"Product_Observational","Modification_History":{"Modification_Detail":{"modification_date":"2020-06-02","description":"Release 5","version_id":1}},"information_model_version":"1.10.1.0","logical_identifier":"urn:nasa:pds:insight_rad:data_raw:hp3_rad_raw_00390_20200101_120222","version_id":1,"title":"InSight HP3 Radiometer Experiment Raw Product:hp3_rad_raw_00390_20200101_120222"},"xmlns":"http://pds.nasa.gov/pds4/pds/v1","Reference_List":{"Internal_Reference":[{"lid_reference":"urn:nasa:pds:insight_documents:document_mission","reference_type":"data_to_document"},{"lid_reference":"urn:nasa:pds:insight_documents:document_hp3rad:hp3_rad_sis","reference_type":"data_to_document"}]},"xsi:schemaLocation":"http://pds.nasa.gov/pds4/pds/v1     \r\n    https://pds.nasa.gov/pds4/pds/v1/PDS4_PDS_1A10.xsd\r\n    \r\n    http://pds.nasa.gov/pds4/mission/insight/v1 \r\n    https://pds.nasa.gov/pds4/mission/insight/v1
...

al-niessner · 2022-01-25T20:50:37Z

@tloubrieu-jpl

With regards to the "method not allowed" and 500 error with some output types, that is because `api-0.5.0-SNAPSHOT' is being used instead of the model that comes with this repository. Took me a while to get the POMs right to make those errors go away.

al-niessner · 2022-01-25T20:52:22Z

@tloubrieu-jpl @jordanpadams

With regards to PDS4 blob. At the breakout it was decode the blob. That is what the blob looks like decoded -- a JSON object. When doing XML should the other blob be decoded or should the JSON object be mapped to XML?

al-niessner · 2022-01-25T21:07:54Z

@tloubrieu-jpl

With regards to build being broken, maybe not. Try doing those searches with fields=lid,lidvid. If that works, then it is because of an elastic search failure.

al-niessner · 2022-01-25T21:15:01Z

@tloubrieu-jpl @jordanpadams

All fields results should be fixed. The elastic search error was from searching for * instead of an empty list. Should be working again.

Sorry for the mistake, but my searches were with fields=lid,lidvid and worked because they replaced the *. Those errors are same as 'api-0.5.0-SNAPSHOT' so just misinterpreted the error until I realized I was using fields in my tests.

tloubrieu-jpl · 2022-01-26T17:27:35Z

api-0.5.0-SNAPSHOT

@tloubrieu-jpl

With regards to the "method not allowed" and 500 error with some output types, that is because `api-0.5.0-SNAPSHOT' is being used instead of the model that comes with this repository. Took me a while to get the POMs right to make those errors go away.

@al-niessner I still have this error, I am not understanding why... i will try mvn dependency to see what is happening

tloubrieu-jpl · 2022-01-26T17:30:49Z

@al-niessner

The command mvn dependency:tree gives

[INFO] +- gov.nasa.pds:registry-api-model:jar:0.5.0-SNAPSHOT:compile
[INFO] |  \- junit:junit:jar:4.13:compile
[INFO] |     \- org.hamcrest:hamcrest-core:jar:2.2:compile
[INFO] +- gov.nasa.pds:registry-api-lexer:jar:1.1.0-SNAPSHOT:compile
[INFO] |  +- org.apache.commons:commons-lang3:jar:3.10:compile
[INFO] |  +- org.slf4j:slf4j-log4j12:jar:1.7.30:compile
[INFO] |  +- log4j:log4j:jar:1.2.17:compile
[INFO] |  +- org.antlr:antlr4:jar:4.9.2:compile
[INFO] |  |  +- org.antlr:antlr-runtime:jar:3.5.2:compile
[INFO] |  |  +- org.antlr:ST4:jar:4.3:compile
[INFO] |  |  +- org.abego.treelayout:org.abego.treelayout.core:jar:1.0.3:compile
[INFO] |  |  +- org.glassfish:javax.json:jar:1.0.4:compile
[INFO] |  |  \- com.ibm.icu:icu4j:jar:61.1:compile
[INFO] |  \- org.antlr:antlr4-runtime-testsuite:jar:4.9.2:compile
[INFO] |     \- org.openjdk.jol:jol-core:jar:0.8:compile

I am building the applcation by running, at the root of the project:

mvn clean install

Then in service folder:

mvn spring-boot:run

Any idea of what I should do ?

Thanks

al-niessner · 2022-01-26T17:34:43Z

@tloubrieu-jpl

You dependency tree, I am not seeing registry-api-service. Did not cut-n-paste it or something more nefarious?

al-niessner · 2022-01-26T17:37:53Z

@tloubrieu-jpl

What curl(s) is failing? All the products without fields are now working for me or were. I am double checking now.

al-niessner · 2022-01-26T17:49:14Z

To have an up-to-date environment, I do the following:

$ ver=pds-api-125 ; docker build --build-arg version=${ver} --file service/docker/Dockerfile.local --tag registry:${ver} .

$ ver=pds-api-125 ; docker run --name registry --network pds  --publish 8080:8080 --rm --volume /home/niessner/Projects/PDS/registry-api/service/src/main/resources/application.properties.docker:/usr/local/registry-${ver}/service/target/classes/application.properties    registry:${ver}

There is a lot of output missing, but these two commands let me do all that I need to get done. I also have an elasticsearch docker running too but you need one of those too.

tloubrieu-jpl · 2022-01-26T17:50:43Z

Thanks @al-niessner , I had a typo in one of my requests which led me to think the other request would not work either. Let me retest them all, that should work.

tloubrieu-jpl

The pr is good to merge. We'll work on the pds4+xml format in a new ticket

al-niessner self-assigned this Jan 5, 2022

al-niessner changed the title ~~moved code~~ pds-api-125: get the XML MIME types working again Jan 5, 2022

Al Niessner added 2 commits January 5, 2022 13:04

get the local build working again

10646fa

allow eclipse to build

9f4fe1e

shorten docker build some more

820c42c

merged main

99813a3