REMOVE jsonParse library including needed adaptations in other parts …

…of the code (unit tests broken at this point)

CMakeLists.txt

@@ -191,7 +191,6 @@ SET (ORION_LIBS
     serviceRoutinesV2
     serviceRoutines
     ngsiNotify
-    jsonParse
     jsonParseV2
     rest          # this is repeated for linking str2Verb from [email protected];
                   # verbName(Verb) from [email protected]
@@ -331,7 +330,6 @@ if (error EQUAL 0)
   ADD_SUBDIRECTORY(src/lib/ngsiNotify)
   ADD_SUBDIRECTORY(src/lib/apiTypesV2)
   ADD_SUBDIRECTORY(src/lib/parse)
-  ADD_SUBDIRECTORY(src/lib/jsonParse)
   ADD_SUBDIRECTORY(src/lib/jsonParseV2)
   ADD_SUBDIRECTORY(src/lib/rest)
   ADD_SUBDIRECTORY(src/lib/mongoBackend)

doc/manuals/devel/architecture.md

@@ -14,11 +14,7 @@ _Current Orion internal architecture_
 
 * The `connectionTreat()` function is the entry point for new requests (see [RQ-01 diagram](sourceCode.md#flow-rq-01) for details). Depending on the version of the NGSI API to which the request belongs (basically, depending whether the request URL prefix is `/v1` or `/v2`) the execution flow goes in one "branch" or another, of the execution logic.
 
-* In the case of NGSIv1 requests (deprecated), the logic is as follows:
-	* First, the [**jsonParse** library](sourceCode.md#srclibjsonparse) takes the request payload as input and generates a set of objects. The NGSIv1 parsing logic is based on the [Boost library property_tree](https://theboostcpplibraries.com/boost.propertytree).
-	* Next, a request servicing function is invoked to process the request. Each request type (in terms of HTTP and URL pattern) has a separate function. We call these functions "service routines" and they reside in the library [**serviceRoutines**](sourceCode.md#srclibserviceroutines). Note that some "high level" service routines may call other "low level" service routines.
-	* At the end (either in one or two hops, see [the mapping document](ServiceRoutines.txt) for details), the service routine calls the **mongoBackend** library.
-* In the case of NGSIv2 requests, the logic is as follows:
+* The logic is as follows:
 	* First, the [**jsonParseV2** library](sourceCode.md#srclibjsonparsev2) takes the request payload as input and generates a set of objects. The NGSIv2 parsing logic is based in [rapidjson](http://rapidjson.org).
 	* Next, similar to NGSIv1, a service routine is called to process the request. Each request type (in terms of HTTP and URL pattern) has a service routine. These "NGSIv2 service routines" reside in the library [**serviceRoutinesV2**](sourceCode.md#srclibserviceroutinesv2). Note that some V2 service routines may call NGSIv1 service routines (see [the mapping document](ServiceRoutines.txt) for details).
 	* At the end, the **mongoBackend** library is invoked. Depending on the case, this can be done directly from a V2 service routine or indirectly via a V1 service routine, as shown in the figure above.

doc/manuals/devel/cprs.md

@@ -55,7 +55,7 @@ _FW-02: `updateForward()` function detail_
 * Parse the context provider string to extract IP, port, URI path, etc. (step 1)
 * The request to forward has to be built (step 2). In the case of NGSIv1, we need to extract information of the binary object into text to be able to send the REST request (plain text) to the Context Provider using `POST /v1/updateContext`. In the case of NGSIv2,  `POST /v2/op/updated` is used.
 * The request to forward is sent with the help of `httpRequestSend()` (step 3), that in its turn uses [libcurl](https://curl.haxx.se/libcurl/) (step 4). libcurl sends in sequence the request to the Context Provider (step 5).
-* The textual response from the Context Provider is parsed and an `UpdateContextResponse` object is created (step 6). Parsing details are provided in diagram [PP-01](jsonParse.md#flow-pp-01).
+* The textual response from the Context Provider is parsed and an `UpdateContextResponse` object is created (step 6). Parsing details are provided in diagram [PP-01](jsonParse.md#flow-pp-01). - FIXME PR: review this
 
 [Top](#top)
 
@@ -91,7 +91,7 @@ _FW-04: `queryForward()` function detail_
 * Parse the context provider string to extract IP, port, URI path, etc. (step 1).
 * The request to forward has to be built (step 2). In the case of NGSIv1, we need to extract information of the binary object into text to be able to send the REST request (plain text) to the Context Provider using `POST /v1/queryContext`. In the case of NGSIv2, `POST /v2/op/query` is used.
 * The request to forward is sent with the help of `httpRequestSend()` (step 3) which uses [libcurl](https://curl.haxx.se/libcurl/) to forward the request (step 4). libcurl sends in sequence the request to the Context Provider (step 5).
-* The textual response from the Context Provider is parsed and an `QueryContextResponse` object is created (step 6). Parsing details are provided in diagram [PP-01](jsonParse.md#flow-pp-01).
+* The textual response from the Context Provider is parsed and an `QueryContextResponse` object is created (step 6). Parsing details are provided in diagram [PP-01](jsonParse.md#flow-pp-01). - FIXME PR: review this
 
 ## A Caveat about shadowing of entities
 The Context Provider mechanism is implemented using standard registration requests and this might lead to unwanted situations.

doc/manuals/devel/flowsIndex.md

@@ -16,7 +16,7 @@ Related to request management (RQ management):
 
 Related to parsing (PP prefix):
 
-* [PP-01: Parsing an NGSIv1 payload](jsonParse.md#flow-pp-01)
+* [PP-01: Parsing an NGSIv1 payload](jsonParse.md#flow-pp-01) - FIXME PR: review this
     * Continues from RQ-02, FW-02 or FW-04 
 * [PP-02: Parsing a text payload](sourceCode.md#flow-pp-02)
 	* Continues from RQ-02