general bug fixes (a collection)

CONTRIBUTING.md

@@ -10,19 +10,40 @@ The concept flow through the code is single threaded down a stack. What this tra
 
 What happens if new code cannot fit into the current concept flow? A refactoring of the concept flow will need to take place and all existing classes will have to be updated to the new structure. This should be resolved before any code changes take place.
 
-Lastly, the code is divided into packages that very roughly group the functionality. It is not well defined and therefore much of the code is smeared about and any clean up of the smearing is welcome - always. Below is a rough definition for each package:
-
-gov.nasa.pds.api.
-
-model.xml - strictly autogenerated code by swagger from model/swagger.yml
-registry - base package that contains interfaces to break circular dependencies and spring-boot content.
-registry.business - supposed to be the PDS specific stuff but it is much more of a hodgepodge at this time.
-registry.configuration - AWS, spring-boot, and swagger configuration information
-registry.controllers - where the user request is bottled into a UserContext or should be but it currently has a lot of business loging in it.
-registry.exceptions - all locally defined exceptions
-registry.lexer - strictly autogenerated code by antlr
-registry.opensearch - required opensearch configuration for a connection and a collection of stuff that binds business needs with opensearch
-registry.serialize - once the business logic is done, these unit seralize them into the request output format (header Accept value).
+The overall architecture/design is the MVC. In this insteance, the controller is the transmutation of uer inputs into the interfaces necessary for the model to fullfil the request. The model represents how the PDS data is stored internally. The view is the serialized output in its appropriate format since that is what the user sees or views.
+
+Lastly, the code is divided into packages that very roughly group the functionality that reflect the MVC architecture/design. While they may not perfectly enforced currently, the implementation is moving in this direction:
+
+**gov.nasa.pds.**
+
+**model**  
+  - strictly autogenerated code by swagger from model/swagger.yml
+
+**api.registry**  
+  - base package that contains  
+    - interfaces to break circular dependencies and improve encapsulation
+    - spring-boot content.
+
+**api.registry.configuration**  
+  - AWS, spring-boot, and swagger configuration information
+
+**api.registry.controller**  
+  - *control* bidirectional transmutation between registry Java design/implementation and the swagger model (auto generated code)
+
+**api.registry.exceptions**  
+  - all locally defined exceptions
+
+**api.registry.lexer**  
+  - strictly autogenerated code by antlr
+
+**api.registry.model**  
+  - supposed to be the model of how the data is stored and organized but it is much more of a hodgepodge at this time.
+
+**api.registry.search**  
+  - required opensearch configuration for a connection and a collection of stuff that binds model needs with opensearch
+
+**api.registry.view**  
+  - once the model has found the needed data, these unit seralize them into the request output format (header Accept value) to complete the request.
 
 All of the interfaces in registry are a Context. What does context mean here. It represents the conceptual flow of information. Many users can access the same endpoint with differnt parameters. These context items hold the state for those individual requests just a context is normally used with program threading. They help separate those classes that need state from that which is purely functional help. In the case of the registry, very little state is needed and is easily represented with these interfaces.
 

README.md

@@ -19,9 +19,7 @@ Based on `docker` you can easily start all the prerequisites as configured in th
     git clone https://github.com/NASA-PDS/registry.git
 
 
-Start the prerequisites:
-
-    docker compose --profile=dev-api up
+Start the prerequisites by following the [Quick Start Guide](https://github.com/NASA-PDS/registry/tree/main/docker#-quick-start-guide---with-default-configurations)
 
 
 ## Start the application from a released package
@@ -53,8 +51,11 @@ Builds the application:
 
 
     cd service
-    mvn sprint-boot:run
+    mvn spring-boot:run
+
+## View Swagger UI
 
+Go to http://localhost:8080
 
 ## Tests
 

docs/requirements/v1.0.1/REQUIREMENTS.md

@@ -0,0 +1,90 @@
+
+Requirements Summary
+====================
+
+# default
+
+## As an API user, I want an average query response time of 1 second for q=* queries ([#69](https://github.com/NASA-PDS/registry-api/issues/69)) 
+
+
+This requirement is not impacted by the current version
+## As an API user, I want to handle long-running queries that take >10 seconds. ([#68](https://github.com/NASA-PDS/registry-api/issues/68)) 
+
+
+This requirement is not impacted by the current version
+## As an operator, I want to have a wrapper script for starting up the API service ([#67](https://github.com/NASA-PDS/registry-api/issues/67)) 
+
+
+This requirement is not impacted by the current version
+## As a user, I want to know why my query syntax is invalid ([#66](https://github.com/NASA-PDS/registry-api/issues/66)) 
+
+
+This requirement is not impacted by the current version
+## As a user,  I want specific end points for products which are not collections or bundles ([#65](https://github.com/NASA-PDS/registry-api/issues/65)) 
+
+
+This requirement is not impacted by the current version
+## As a user, I want the /products end point to work for any class of products ([#64](https://github.com/NASA-PDS/registry-api/issues/64)) 
+
+
+This requirement is not impacted by the current version
+## As a user, I want the end-point /api to redirect to the API documentation ([#63](https://github.com/NASA-PDS/registry-api/issues/63)) 
+
+
+This requirement is not impacted by the current version
+## As a user, I want to have singular urls when I should only expect a single element in the response ([#61](https://github.com/NASA-PDS/registry-api/issues/61)) 
+
+
+This requirement is not impacted by the current version
+## As a user, I want to see the version of the API specification in the URL of the service ([#59](https://github.com/NASA-PDS/registry-api/issues/59)) 
+
+
+This requirement is not impacted by the current version
+## As a user, I want to see the version of the API specification in the URL of the service ([#8](https://github.com/NASA-PDS/registry-api/issues/8)) 
+
+
+This requirement is not impacted by the current version
+## As a user, I want the /products end point to work for any class of products ([#11](https://github.com/NASA-PDS/registry-api/issues/11)) 
+
+
+This requirement is not impacted by the current version
+## As a user,  I want specific end points for products which are not collections or bundles ([#12](https://github.com/NASA-PDS/registry-api/issues/12)) 
+
+
+This requirement is not impacted by the current version
+## As a user, I want to know why my query syntax is invalid ([#13](https://github.com/NASA-PDS/registry-api/issues/13)) 
+
+
+This requirement is not impacted by the current version
+## As an operator, I want to have a wrapper script for starting up the API service ([#14](https://github.com/NASA-PDS/registry-api/issues/14)) 
+
+
+This requirement is not impacted by the current version
+## As an API user, I want to handle long-running queries that take >10 seconds. ([#15](https://github.com/NASA-PDS/registry-api/issues/15)) 
+
+
+This requirement is not impacted by the current version
+## As an API user, I want an average query response time of 1 second for q=* queries ([#16](https://github.com/NASA-PDS/registry-api/issues/16)) 
+
+
+This requirement is not impacted by the current version
+## As an API caller(user) I want to specify fields for endpoints given a lidvid ([#80](https://github.com/NASA-PDS/registry-api/issues/80)) 
+
+
+This requirement is not impacted by the current version
+## the default proposed mime type in swagger-ui.html should be 'application/json' ([#88](https://github.com/NASA-PDS/registry-api/issues/88)) 
+
+
+This requirement is not impacted by the current version
+## As a user, I want to have an administrator contact when I am getting an error 500 from the server ([#109](https://github.com/NASA-PDS/registry-api/issues/109)) 
+
+
+This requirement is not impacted by the current version
+## As a user I want consistent /type/lidvlid/{child,parent}/{latest,all} ([#126](https://github.com/NASA-PDS/registry-api/issues/126)) 
+
+
+This requirement is not impacted by the current version
+## As a user, I want to get the product identifiers in a application/kvp+json format ([#132](https://github.com/NASA-PDS/registry-api/issues/132)) 
+
+
+This requirement is not impacted by the current version

model/pom.xml

@@ -120,27 +120,22 @@
     <!--SpringFox dependencies -->
     <dependency>
       <groupId>io.springfox</groupId>
-      <artifactId>springfox-swagger2</artifactId>
-      <version>${springfox-version}</version>
-    </dependency>
-    <dependency>
-      <groupId>io.springfox</groupId>
-      <artifactId>springfox-swagger-ui</artifactId>
-      <version>${springfox-version}</version>
-    </dependency>
-
+      <artifactId>springfox-boot-starter</artifactId>
+      <version>3.0.0</version>
+    </dependency>    
+
     <!-- https://mvnrepository.com/artifact/org.springframework/spring-web -->
     <dependency>
       <groupId>org.springframework</groupId>
       <artifactId>spring-web</artifactId>
-      <version>5.3.19</version>
+      <version>5.3.20</version>
     </dependency>
 
     <!-- https://mvnrepository.com/artifact/org.springframework/spring-context -->
     <dependency>
       <groupId>org.springframework</groupId>
       <artifactId>spring-context</artifactId>
-      <version>5.3.19</version>
+      <version>5.3.20</version>
     </dependency>