Preparing for the 2.11.11 release. Filling Technical doc with that of…

… Context
adobe · Sep 10, 2023 · 1cef1ff · 1cef1ff
1 parent 18dbc19
commit 1cef1ff
Show file tree

Hide file tree

Showing 4 changed files with 49 additions and 25 deletions.
diff --git a/README.md b/README.md
@@ -68,7 +68,7 @@ The following dependency needs to be added to your pom file:
  <dependency>
     <groupId>com.adobe.campaign.tests.bridge.service</groupId>
     <artifactId>integroBridgeService</artifactId>
-    <version>2.11.10</version>
+    <version>2.11.11</version>
 </dependency>
 ```
 
@@ -341,7 +341,7 @@ One of our main concerns has been the management of static variables. For the sa
 #### Session Scopes
 For now our approach is that two distinct calls to the same Bridge Service node, should share little or no variables. Another way of defining this is that two calls should not interfere with one another. In a Session Context we have two use cases:
 
-We have covered all the use cases in the document [Managing Contexts and Static Variables](docs/Context.md).
+We have covered all the use cases in the document [Managing Contexts and Static Variables](./docs/Technical.md#managing-contexts-and-static-variables).
 
 #### Product Scope
 Although we do not, yet, provide tools for managing variables that are valid for all calls to the IBS, we can define a series or local environment variables are deployment of the service. This can be done in two ways:

diff --git a/ReleaseNotes.md b/ReleaseNotes.md
@@ -1,46 +1,46 @@
 # Bridge Service - RELEASE NOTES
-## 2.11.11 (SNAPSHOT)
-This is the first version that is on the public github. Hence we have the issue numbers being reset.
+## 2.11.11
 * [#43 Introduce automatic loading of classes](https://github.com/adobe/bridgeService/issues/43): Instead of selectively loading classes from designated packages, we now load all needed classes in the class loader.
 * [#34 java.lang.LinkageError: loader constraint violation: loader 'app' (instance of jdk.internal.loader.ClassLoaders](https://github.com/adobe/bridgeService/issues/34): Discovered a problem with Linkage error when using the traditional class loader. We now load everything locally, this means that all static variables are stored in the context (Issue #43).
-* We started reorganizing the errors, and have started doing a more predefined error management.
+* We started reorganizing the errors, and have started doing a more predefined error management. For more info please refer to the [Technical Documentation](./docs/Technical.md) .
 * [#35 When calling a class with no modifiers we do not get enough information](https://github.com/adobe/bridgeService/issues/35)
 * [#37 Better error formatting](https://github.com/adobe/bridgeService/issues/37) We now end errors as a JSON data including errors and messages.
 * [#36 Make the /test endpoint return a JSON](https://github.com/adobe/bridgeService/issues/37) By sending the /test data as json we make it more legible.
 * [#38 Better information if the deployment port is already in use ](https://github.com/adobe/bridgeService/issues/38) Whenever we are starting the bridgeService on a port that is already in use, we throw a IBSConfigurationException exception.
-
+* Merged the document `./docs/Context.md` into the `./docs/Technical.md` document.
 
 ## 2.11.10
-* [#57 Call Timeout Management](https://git.corp.adobe.com/AdobeCampaignQE/integroBridgeService/issues/57): Introducing the timeout, mechanism. We have a global timeout, and a call session timeout. We also log the individual call durations in the return payload.
-* [#58 Object Instance Management](https://git.corp.adobe.com/AdobeCampaignQE/integroBridgeService/issues/58): We can now instantiate objects and call their instance methods.
-* [#60 Integro Independance](https://git.corp.adobe.com/AdobeCampaignQE/integroBridgeService/issues/60): We are now completely independant of integro as a library. For testing purposes we now use dedicated classes that are available in the module "bridgeService-data". This can be included in a deployment by setting `demo.project.mode=compile`.
-* [#63 multi-module solution](https://git.corp.adobe.com/AdobeCampaignQE/integroBridgeService/issues/63): Moved to a multi-module approach. This we can better manage and maintain the dependant test classes.
-* [#21 Public GitHub](https://github.com/adobe/bridgeService/issues/21): Migrated from the Adobe Enterprise artefactory to the public GitHub, adapted deployment scripts and devOps methods.
-* [#20 Available JavaDoc](https://github.com/adobe/bridgeService/issues/20): Made the javaDoc available.
+This is the first version that is on the public github. Hence we have the issue numbers being reset. Old issue titles are marked in bold:
+* **Call Timeout Management**: Introducing the timeout, mechanism. We have a global timeout, and a call session timeout. We also log the individual call durations in the return payload.
+* **Object Instance Management** : We can now instantiate objects and call their instance methods.
+* **Integro Independance**: We are now completely independant of integro as a library. For testing purposes we now use dedicated classes that are available in the module "bridgeService-data". This can be included in a deployment by setting `demo.project.mode=compile`.
+* **multi-module solution**: Moved to a multi-module approach. This we can better manage and maintain the dependant test classes.
+* **Public GitHub**: Migrated from the Adobe Enterprise artefactory to the public GitHub, adapted deployment scripts and devOps methods.
+* **Available JavaDoc**: Made the javaDoc available.
 
 ## 2.11.5
-* [#56 Java 11 Compatibility](https://git.corp.adobe.com/AdobeCampaignQE/integroBridgeService/issues/56).Integro Bridge Service is now Java 11 compatible. From now on the standard builds are in Java 11. (Java 8 is also available, but is made on demand).
-* [#48 Dynamically load all called classes](https://git.corp.adobe.com/AdobeCampaignQE/integroBridgeService/issues/48). Previously, we were loading a preset set of packages for managing the static variable contexts in calls. We now automatically include the classes that are being called. This solves the following issues:
-  * [#41 Ensuring that the system value handler is included in the static paths](https://git.corp.adobe.com/AdobeCampaignQE/integroBridgeService/issues/41) : We were discovering that static variables are not automatically included in the static cpath context.
-  * [#47 Issue with Server=null when calling PushNotifications with IBS](https://git.corp.adobe.com/AdobeCampaignQE/integroBridgeService/issues/47) : We discovered that when the environment variables are in one context, and that the following java call isn't, we would not have access to those variables.
+* **Java 11 Compatibility**: Integro Bridge Service is now Java 11 compatible. From now on the standard builds are in Java 11. (Java 8 is also available, but is made on demand).
+* **Dynamically load all called classes**: Previously, we were loading a preset set of packages for managing the static variable contexts in calls. We now automatically include the classes that are being called. This solves the following issues:
+  * **Ensuring that the system value handler is included in the static paths**: We were discovering that static variables are not automatically included in the static cpath context.
+  * **Issue with Server=null when calling PushNotifications with IBS**: We discovered that when the environment variables are in one context, and that the following java call isn't, we would not have access to those variables.
 * Renamed Configuration class `com.adobe.campaign.tests.service.ConfigValueHandler` to `com.adobe.campaign.tests.bridge.service.ConfigValueHandlerIBS`. This is to avoid confligt with projects using the same design pattern.
 * Added Continuous Integration Scripts.
 
 ## 2.0.4
-* [#44 Environment variables are always strings](https://git.corp.adobe.com/AdobeCampaignQE/integroBridgeService/issues/44). Facing issues with integegers in environment variables not being picked up, we decided to force all environment variables as Strings.
+* **Environment variables are always strings**: Facing issues with integegers in environment variables not being picked up, we decided to force all environment variables as Strings.
   * We now include two new Exceptions:
     * IBSConfigurationException : thrown whenever the configuration we set (currently only for the setting of the environment variables) does not match an existing class/method.
     * IBSRunTimeException : When for some reason the payload has issues non-related to JSON.
 
 ## 2.0.0
 * Implementation of the Injection model. IntegroBridgeService is added as a dependency in projects and can now be spawned in any environment.
-  * [#6 Move from an aggregator model to an insertion model. From now on IBS is put in the libraries that we want to interface.](https://git.corp.adobe.com/AdobeCampaignQE/integroBridgeService/issues/6)
-  * [#27 externalizing environment variables](https://git.corp.adobe.com/AdobeCampaignQE/integroBridgeService/issues/27)
-  * [#29 Updated the README to include clearer information about call chaining](https://git.corp.adobe.com/AdobeCampaignQE/integroBridgeService/issues/29)
-  * [#32 The classpath is no longer hard-coded](https://git.corp.adobe.com/AdobeCampaignQE/integroBridgeService/issues/32)
-  * [#26 introduced continuous integration](https://git.corp.adobe.com/AdobeCampaignQE/integroBridgeService/issues/26)
-  * [#36 Allow projects injecting the IBS to append their version number to the IBS test end point](https://git.corp.adobe.com/AdobeCampaignQE/integroBridgeService/issues/36)
-  * [#31 Make SSL params in main configurble](https://git.corp.adobe.com/AdobeCampaignQE/integroBridgeService/issues/31)
+  * Move from an aggregator model to an insertion model. From now on IBS is put in the libraries that we want to interface.
+  * externalizing environment variables
+  * Updated the README to include clearer information about call chaining
+  * The classpath is no longer hard-coded
+  * introduced continuous integration
+  * Allow projects injecting the IBS to append their version number to the IBS test end point
+  * Make SSL params in main configurble
 
 ## 1.0.0
 * First working version. Using Aggregator model, containing Integro-ACC
diff --git a/docs/Context.md b/docs/Context.md
@@ -16,7 +16,7 @@ In some cases we want to have control over the classes and packages that are loa
 
 Semi-Manual Loading will statically load the classes you call.
 
-## Managing Environment Variables and Calls 
+### Managing Environment Variables and Calls 
 This page describes the state of how Calls access static variables. The structure is the following:
 1. Environment Variable Setting
 2. Calling Java

diff --git a/docs/Technical.md b/docs/Technical.md
@@ -10,3 +10,27 @@ We currently manage the following error types.
 | 408        | IBSTimeOutException                                                                | When the underlying java call takes too long to execute.   |
 | 500        | IBSConfigurationException, IBSRunTimeException, TargetJavaMethodCallException      | Errors happening when calling the underlying Java classes. |
 
+## Managing Contexts and Static Variables
+We have three modes of Integrity management :
+* Automatic
+* Semi-Manual
+* Manual
+
+These modes can be set by changing the system property `IBS.CLASSLOADER.AUTOMATIC.INTEGRITY.INJECTION`.
+
+### Automatic Loading
+Automatic loading assumes that all classes that are accessed by the called system should be loaded in the context. In this case we do not need to specify what should be managed by the local class loader and what by the standard loader. The drawback of this is that some more memory will be needed (5%).
+
+This is the default behavior, and it kicks in even when a wrong value is given for the execution property `IBS.CLASSLOADER.AUTOMATIC.INTEGRITY.INJECTION`.
+
+### Manual Loading
+In some cases we want to have control over the classes and packages that are loaded into the Class Loader. In this case we load a minimal number of classes in the IBS classLoader. The drawback of this is that the controls are a little more complex.
+
+Semi-Manual Loading will statically load the classes you call.
+
+#### Managing Environment Variables and Calls
+This page describes the state of how Calls access static variables. The structure is the following:
+1. Environment Variable Setting
+2. Calling Java
+3. (optional) Environment Variable Setting
+4. Calling Java