general bug fixes (a collection) (#166)

* Issue 131: increase adaptability (#142) * endpoints Had to change the planned endpoints to /gid/{group name} to /pid/{lidvid}. Also had to add /gid and /pid as prefixes for the referencing endpoints as well. The point really is that had to add the prefixes is because swagger cannot tell /{group name} from /{lidvid} even though the group names are a well defined enum. The prefixes allow swagger to identify the endpoints as unique. While the actual characters gid and pid are not required, whatever is chosen must be unique and different. * reshape the architecture/design The base architecture is MVC, but the code does not directly represent it. Moved business to model and serializer to view to match the architecture. Reduced the multiple controllers to one and use a facade/plug-n-play pattern (ReferencingLogic) to manage the polymorphism needed for each of the ancestral paths to find information. Added a Java enum to do the mapping among the group names and the product class in the data itself. The enum holds the ReferencingLogic allowing either side (controller or model) to work with the given inputs and collect the desired output. Most of the code in the DAO objects moved to ReferencingLogic implementations. These objects understand the relationship between model elements and internalize the relationship as code. An example is for bundles finding their grandchildren. * CONTRIBUTING.md updated Once the refactoring was complete, updated the documentation to reflect the new code naming and its relationship to the architecture/design. * docker update by Jimmie Young <[email protected]> * Add a Dockerfile for building images for AWS deployments (#151) * Creation of AWS-specific Dockerfile, update README to indicate its purpose * Fix typo in both Dockerfiles (extraneous ']' in CMD) * Anonymous changes from main stomp * Switch back to 8080 by default (#157) * fix for 141 (#147) (#156) * changed string searching (#158) by Al Niessner <[email protected]> Seems that wildcards is not well implemented in the later elasticsearch and opensearch implementations. The most recent documentation for either has changed significantly that if searhing for strings, then they offer a short globish like set of patterns. Moved from using wildcards to this new string and it seems to be working. The eq operator had some problems because it was using should instead of filter for the or condition. SHould returns everything with a score value to represent the closes match from the furthest. Changed over to filter and the or condition is now behaving as expected. * Anonymous changes from main stomp * fixes for issue 162 * fixes for issue 162 * fix for issue 149
NASA-PDS · Aug 16, 2022 · fe04962 · fe04962
1 parent 6deaab8
commit fe04962
Show file tree

Hide file tree

Showing 97 changed files with 2,237 additions and 2,435 deletions.
diff --git a/CONTRIBUTING.md b/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.
 

diff --git a/README.md b/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
 

diff --git a/docs/requirements/v1.0.1/REQUIREMENTS.md b/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
diff --git a/model/pom.xml b/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>