/bin/release .
```
-##Aliases
+## Aliases
Running the different stages of the buildpack lifecycle can be made simpler with the use of aliases and an environment variable to point at your local copy of the buildpack. The examples below pass in `.` to the scripts assuming you are calling them from the local working directory.
```bash
$ alias detect='$BUILDPACK_ROOT/bin/detect .'
$ alias compile='$BUILDPACK_ROOT/bin/compile . $TMPDIR'
-$ alias release='$BUILDPACK_ROOT/bin/release . | ruby -e "require \"yaml\"; puts YAML.load(STDIN.read)[\"default_process_types\"][\"web\"]"'
+$ alias release='$BUILDPACK_ROOT/bin/release . | ruby -e "require \"yaml\"; puts YAML.load(STDIN.read)[\"default_process_types\"][\"web\"]" | sed "s| exec||"'
```
[d]: extending-logging.md#configuration
diff --git a/docs/example-embedded-web-server.md b/docs/example-embedded-web-server.md
new file mode 100644
index 0000000000..52d7291a9d
--- /dev/null
+++ b/docs/example-embedded-web-server.md
@@ -0,0 +1,30 @@
+# Embedded web server examples
+
+The Java Buildpack can run applications which provide their own web server or servlet container, provided as JAR files.
+
+## Example
+
+This example uses Jetty as an embedded web server, but should be applicable for other technologies.
+
+```java
+
+public static void main(String[] args) {
+ int port = Integer.parseInt(System.getenv("PORT"));
+ Server server = new Server(port);
+ server.setHandler(new AbstractHandler() {
+ @Override
+ public void handle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
+ response.setContentType("text/html;charset=utf-8");
+ response.setStatus(HttpServletResponse.SC_OK);
+ baseRequest.setHandled(true);
+ response.getWriter().println("Hello, world
");
+ }
+ });
+ server.start();
+ server.join();
+}
+```
+
+The important takeaway is to note that the port comes from the environment variable `port`. Other variables are detailed in the [Cloud Foundry developer guide](http://docs.cloudfoundry.org/devguide/deploy-apps/environment-variable.html). When the application is built as an executable JAR file, it will be treated as a [Java Main](https://github.com/cloudfoundry/java-buildpack/blob/master/docs/example-java_main.md) application.
+
+
diff --git a/docs/example-servlet.md b/docs/example-servlet.md
index d7a212dfd3..4a4932040b 100644
--- a/docs/example-servlet.md
+++ b/docs/example-servlet.md
@@ -26,7 +26,7 @@ The following example shows how deploy the sample application located in the [Ja
```bash
$ mvn package
-$ cf push web-servlet-2-application -p target/web-servlet-2-application-1.0.0.BUILD-SNAPSHOT.war -b https://github.com/cloudfoundry/java-buildpack.git -b https://github.com/cloudfoundry/java-buildpack.git
+$ cf push web-servlet-2-application -p target/web-servlet-2-application-1.0.0.BUILD-SNAPSHOT.war -b https://github.com/cloudfoundry/java-buildpack.git
-----> Downloading Open Jdk JRE 1.7.0_51 from http://.../openjdk/lucid/x86_64/openjdk-1.7.0_51.tar.gz (0.0s)
Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (1.1s)
diff --git a/docs/extending-application.md b/docs/extending-application.md
index a8c0bb6a1d..af904e05f5 100644
--- a/docs/extending-application.md
+++ b/docs/extending-application.md
@@ -38,8 +38,11 @@ A helper type (`JavaBuildpack::Component::Services`) that enables querying of th
# +filter+ matches exactly one service, +false+ otherwise.
#
# @param [Regexp, String] filter a +RegExp+ or +String+ to match against the name, label, and tags of the services
-# @return [Boolean] +true+ if the +filter+ matches exactly one service, +false+ otherwise.
-def one_service?(filter)
+# @param [String] required_credentials an optional list of keys or groups of keys, where at least one key from the
+# group, must exist in the credentials payload of the candidate service
+# @return [Boolean] +true+ if the +filter+ matches exactly one service with the required credentials, +false+
+# otherwise.
+def one_service?(filter, *required_credentials)
# Compares the name, label, and tags of each service to the given +filter+. The method returns the first service
# that the +filter+ matches. If no service matches, returns +nil+
diff --git a/docs/extending-base_component.md b/docs/extending-base_component.md
index 1643fadf85..836812a2a8 100644
--- a/docs/extending-base_component.md
+++ b/docs/extending-base_component.md
@@ -48,7 +48,7 @@ def release
# @param [String] uri
# @param [String] name an optional name for the download. Defaults to +@component_name+.
# @return [Void]
-def download(version, uri, name = @component_name, &block)
+def download(version, uri, name = @component_name)
# Downloads a given JAR file and stores it.
#
@@ -57,6 +57,7 @@ def download(version, uri, name = @component_name, &block)
# @param [String] jar_name the name to save the jar as
# @param [Pathname] target_directory the directory to store the JAR file in. Defaults to the component's sandbox.
# @param [String] name an optional name for the download. Defaults to +@component_name+.
+# @return [Void]
def download_jar(version, uri, jar_name, target_directory = @droplet.sandbox, name = @component_name)
# Downloads a given TAR file and expands it.
@@ -65,6 +66,7 @@ def download_jar(version, uri, jar_name, target_directory = @droplet.sandbox, na
# @param [String] uri the uri of the download
# @param [Pathname] target_directory the directory to expand the TAR file to. Defaults to the component's sandbox.
# @param [String] name an optional name for the download and expansion. Defaults to +@component_name+.
+# @return [Void]
def download_tar(version, uri, target_directory = @droplet.sandbox, name = @component_name)
# Downloads a given ZIP file and expands it.
@@ -72,11 +74,13 @@ def download_tar(version, uri, target_directory = @droplet.sandbox, name = @comp
# @param [Boolean] strip_top_level whether to strip the top-level directory when expanding. Defaults to +true+.
# @param [Pathname] target_directory the directory to expand the ZIP file to. Defaults to the component's sandbox.
# @param [String] name an optional name for the download. Defaults to +@component_name+.
+# @return [Void]
def download_zip(version, uri, strip_top_level = true, target_directory = @droplet.sandbox, name = @component_name)
# Wrap the execution of a block with timing information
#
# @param [String] caption the caption to print when timing starts
+# @return [Void]
def with_timing(caption)
```
diff --git a/docs/extending-caches.md b/docs/extending-caches.md
index 512d8680f1..0489516005 100644
--- a/docs/extending-caches.md
+++ b/docs/extending-caches.md
@@ -39,32 +39,36 @@ end
```
## Configuration
-For general information on configuring the buildpack, refer to [Configuration and Extension][].
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
Caching can be configured by modifying the [`config/cache.yml`][] file in the buildpack fork.
| Name | Description
| ---- | -----------
| `remote_downloads` | This property can take the value `enabled` or `disabled`. The default value of `enabled` means that the buildpack will check the internet connection and remember the result for the remainder of the buildpack invocation. If the internet is available, it will then be used to download files. If the internet is not available, cache will be consulted instead.
Alternatively, the property may be set to `disabled` which avoids the check for an internet connection, does not attempt downloads, and consults the cache instead.
+| `client_authentication.certificate_location` | The path to a PEM or DER encoded certificate to use for SSL client certificate authentication
+| `client_authentication.private_key_location` | The path to a PEM or DER encoded DSA or RSA private key to use for SSL client certificate authentication
+| `client_authentication.private_key_password` | The password for the private key to use for SSL client certificate authentication
## `JavaBuildpack::Util::Cache::DownloadCache`
The [`DownloadCache`][] is the most generic of the two caches. It allows you to create a cache that persists files any that write access is available. The constructor signature looks the following:
```ruby
-# Creates an instance of the cache that is backed by the filesystem rooted at +cache_root+
+# Creates an instance of the cache that is backed by a number of filesystem locations. The first argument
+# (+mutable_cache_root+) is the only location that downloaded files will be stored in.
#
-# @param [String] cache_root the filesystem root for downloaded files to be cached in
-def initialize(cache_root = Dir.tmpdir)
+# @param [Pathname] mutable_cache_root the filesystem location in which find cached files in. This will also be
+# the location that all downloaded files are written to.
+# @param [Pathname] immutable_cache_roots other filesystem locations to find cached files in. No files will be
+# written to these locations.
+def initialize(mutable_cache_root = Pathname.new(Dir.tmpdir), *immutable_cache_roots)
```
## `JavaBuildpack::Util::Cache::ApplicationCache`
The [`ApplicationCache`][] is a cache that persists files into the application cache passed to the `compile` script. It examines `ARGV[1]` for the cache location and configures itself accordingly.
```ruby
-# Creates an instance that is configured to use the application cache. The application cache location is defined by
-# the second argument (ARGV[1]) to the +compile+ script.
-#
-# @raise if the second argument (ARGV[1]) to the +compile+ script is +nil+
+# Creates an instance of the cache that is backed by the the application cache
def initialize
```
diff --git a/docs/extending-droplet.md b/docs/extending-droplet.md
index 798bfa0dbe..51988ddf2e 100644
--- a/docs/extending-droplet.md
+++ b/docs/extending-droplet.md
@@ -32,7 +32,8 @@ attr_reader :sandbox
# Copy resources from a components resources directory to a directory
#
-# @param [Pathname] target_directory the directory to copy to. Default to a component's +sandbox+
+# @param [Pathname] target_directory the directory to copy to. Defaults to the component's +sandbox+.
+# @return [Void]
def copy_resources(target_directory = @sandbox)
```
@@ -48,6 +49,7 @@ def as_classpath
# Symlink the contents of the collection to a destination directory.
#
# @param [Pathname] destination the destination to link to
+# @return [Void]
def link_to(destination)
```
@@ -58,7 +60,7 @@ The id of the component, as determined by the buildpack. This is used in variou
One of two helper types (`JavaBuildpack::Component::ImmutableJavaHome`, `JavaBuildpack::Component::MutableJavaHome`) that enables the mutation and retrieval of the droplet's `JAVA_HOME`. Components that are JREs will be given the `MutableJavaHome` in order to set the value. All other components will be given the `ImmutableJavaHome` in order to retrieve the value.
```ruby
-# Returns the path of +JAVA_HOME+ as an environment variable formatted as +JAVA_HOME="$PWD/"+
+# Returns the path of +JAVA_HOME+ as an environment variable formatted as +JAVA_HOME=$PWD/+
#
# @return [String] the path of +JAVA_HOME+ as an environment variable
def as_env_var
@@ -66,9 +68,10 @@ def as_env_var
# Execute a block with the +JAVA_HOME+ environment variable set
#
# @yield yields to block with the +JAVA_HOME+ environment variable set
+# @return [Object] the returned value of the block
def do_with
-# @return [String] the root of the droplet's +JAVA_HOME+
+# @return [String] the root of the droplet's +JAVA_HOME+ formatted as +$PWD/+
def root
# Sets the root of the droplet's +JAVA_HOME+
diff --git a/docs/extending-logging.md b/docs/extending-logging.md
index 055554f835..a8f7a26241 100644
--- a/docs/extending-logging.md
+++ b/docs/extending-logging.md
@@ -24,7 +24,7 @@ logger.debug { "#{costly_method}" }
```
## Configuration
-For general information on configuring the buildpack, refer to [Configuration and Extension][].
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
The console logging severity filter is set to `DEBUG`, `INFO`, `WARN`, `ERROR`, `FATAL` using the following strategies in descending priority:
diff --git a/docs/extending-modular_component.md b/docs/extending-modular_component.md
index 8760e930a9..e61e7649e7 100644
--- a/docs/extending-modular_component.md
+++ b/docs/extending-modular_component.md
@@ -10,11 +10,12 @@ This base class is recommended for use by any component that is sufficiently com
# components are expected to return the command required to run the application.
def command
-# The modules that make up this component
+# The sub_components that make up this component
#
# @param [Hash] context the context of the component
-# @return [Array] a collection of +BaseComponent+s that make up the modules of this component
-def modules(context)
+# @return [Array] a collection of +BaseComponent+s that make up the sub_components of this
+# component
+def sub_components(_context)
# Whether or not this component supports this application
#
diff --git a/docs/extending-repositories.md b/docs/extending-repositories.md
index 84604ef680..9d7854f17d 100644
--- a/docs/extending-repositories.md
+++ b/docs/extending-repositories.md
@@ -22,15 +22,17 @@ An example filesystem might look like:
The main class used when dealing with a repository is [`JavaBuildpack::Repository::ConfiguredItem`][]. It provides a single method that is used to resolve a specific version and its URI.
```ruby
-# Finds an instance of the file based on the configuration.
+# Finds an instance of the file based on the configuration and wraps any exceptions
+# to identify the component.
#
+# @param [String] component_name the name of the component
# @param [Hash] configuration the configuration
# @option configuration [String] :repository_root the root directory of the repository
# @option configuration [String] :version the version of the file to resolve
# @param [Block, nil] version_validator an optional version validation block
-# @return [JavaBuildpack::Util::TokenizedVersion] the chosen version of the file
# @return [String] the URI of the chosen version of the file
-def find_item(configuration, &version_validator)
+# @return [JavaBuildpack::Util::TokenizedVersion] the chosen version of the file
+def find_item(component_name, configuration)
```
Usage of the class might look like the following:
@@ -52,12 +54,12 @@ end
| Variable | Description |
| -------- | ----------- |
-| `{default.repository.root}` | The common root for all repositories. Currently defaults to `http://download.pivotal.io.s3.amazonaws.com`.
-| `{platform}` | The platform that the application is running on. Currently detects `centos6`, `lucid`, `mountainlion`, and `precise`.
+| `{default.repository.root}` | The common root for all repositories. Currently defaults to `https://java-buildpack.cloudfoundry.org`.
+| `{platform}` | The platform that the application is running on. Currently detects `jammy`, `noble`, etc.
| `{architecture}` | The architecture of the system as returned by Ruby. The value is typically one of `x86_64` or `x86`.
## Configuration
-For general information on configuring the buildpack, refer to [Configuration and Extension][].
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
Repositories can be configured by modifying the [`config/repository.yml`][] file in the buildpack fork.
@@ -93,5 +95,5 @@ In addition to declaring a specific versions to use, you can also specify a boun
[`config/repository.yml`]: ../config/repository.yml
[`JavaBuildpack::Repository::ConfiguredItem`]: ../lib/java_buildpack/repository/configured_item.rb
[Configuration and Extension]: ../README.md#configuration-and-extension
-[example]: http://download.pivotal.io.s3.amazonaws.com/openjdk/lucid/x86_64/index.yml
+[example]: https://java-buildpack.cloudfoundry.org/openjdk/jammy/x86_64/index.yml
diff --git a/docs/extending.md b/docs/extending.md
index 9cb95f93ce..d90b05c8a1 100644
--- a/docs/extending.md
+++ b/docs/extending.md
@@ -1,7 +1,7 @@
# Extending
For general information on extending the buildpack, refer to [Configuration and Extension](../README.md#configuration-and-extension).
-To add a component, its class name must be added added to [`config/components.yml`][]. It is recommended, but not required, that the class' file be placed in a directory that matches its type.
+To add a component, its class name must be added to [`config/components.yml`][]. It is recommended, but not required, that the class' file be placed in a directory that matches its type.
| Component Type | Location
| -------------- | --------
diff --git a/docs/framework-app_dynamics_agent.md b/docs/framework-app_dynamics_agent.md
index 28d7dcaab5..e1ec4a53e0 100644
--- a/docs/framework-app_dynamics_agent.md
+++ b/docs/framework-app_dynamics_agent.md
@@ -1,9 +1,9 @@
# AppDynamics Agent Framework
-The AppDynamics Agent Framework causes an application to be automatically configured to work with a bound [AppDynamics Service][].
+The AppDynamics Agent Framework causes an application to be automatically configured to work with a bound [AppDynamics Service][]. **Note:** This framework is disabled by default.
- | Detection Criterion | Existence of a single bound AppDynamics service. The existence of an AppDynamics service defined by the VCAP_SERVICES payload containing a service name, label or tag with app-dynamics as a substring.
+ | Detection Criterion | Existence of a single bound AppDynamics service. The existence of an AppDynamics service defined by the VCAP_SERVICES payload containing a service name, label or tag with app-dynamics or appdynamics as a substring.
|
@@ -13,34 +13,87 @@ The AppDynamics Agent Framework causes an application to be automatically config
Tags are printed to standard output by the buildpack detect script
## User-Provided Service
-When binding AppDynamics using a user-provided service, it must have name or tag with `app-dynamics` in it. The credential payload can contain the following entries:
+When binding AppDynamics using a user-provided service, it must have name or tag with `app-dynamics` or `appdynamics` in it. The credential payload can contain the following entries.
| Name | Description
| ---- | -----------
-| `account-access-key` | (Optional) The account access key to use when authenticating with the controller
-| `account-name` | (Optional) The account name to use when authenticating with the controller
+| `account-access-key` | The account access key to use when authenticating with the controller
+| `account-name` | The account name to use when authenticating with the controller
| `host-name` | The controller host name
-| `port` | (Optional) The controller port
-| `ssl-enabled` | (Optional) Whether or not to use an SSL connection to the controller
+| `port` | The controller port
+| `ssl-enabled` | Whether or not to use an SSL connection to the controller
+| `application-name` | (Optional) the application's name
+| `node-name` | (Optional) the application's node name
| `tier-name` | (Optional) the application's tier name
+To provide more complex values such as the `tier-name`, using the interactive mode when creating a user-provided service will manage the character escaping automatically. For example, the default `tier-name` could be set with a value of `Tier-$(expr "${VCAP_APPLICATION}" : '.*instance_index[": ]*\([[:digit:]]*\).*')` to calculate a value from the Cloud Foundry instance index.
+
+**Note:** Some credentials were previously marked as "(Optional)" as requirements have changed across versions of the AppDynamics agent. Please see the [AppDynamics Java Agent Configuration Properties][] for the version of the agent used by your application for more details.
+
## Configuration
-For general information on configuring the buildpack, refer to [Configuration and Extension][].
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
-The framework can be configured by modifying the [`config/app_dynamics_agent.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+The framework can be configured by modifying the [`config/app_dynamics_agent.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
| Name | Description
| ---- | -----------
-| `default_tier_name` | The default tier name for this application in the AppDynamics dashboard. This can be overridden with a `tier-name` entry in the credentials payload.
+| `default_application_name` | This is omitted by default but can be added to specify the application name in the AppDynamics dashboard. This can be overridden by an `application-name` entry in the credentials payload. If neither are supplied the default is the `application_name` as specified by Cloud Foundry.
+| `default_node_name` | The default node name for this application in the AppDynamics dashboard. The default value is an expression that will be evaluated based on the `instance_index` of the application. This can be overridden by a `node-name` entry in the credentials payload.
+| `default_tier_name` | This is omitted by default but can be added to specify the tier name for this application in the AppDynamics dashboard. This can be overridden by a `tier-name` entry in the credentials payload. If neither are supplied the default is the `application_name` as specified by Cloud Foundry.
| `repository_root` | The URL of the AppDynamics repository index ([details][repositories]).
| `version` | The version of AppDynamics to use. Candidate versions can be found in [this listing][].
### Additional Resources
-The framework can also be configured by overlaying a set of resources on the default distribution. To do this, add files to the `resources/app_dynamics_agent` directory in the buildpack fork. For example, to override the default `app-agent-config.xml` add your custom file to `resources/app_dynamics_agent/conf/app-agent-config.xml`.
+The framework can also be configured by overlaying a set of resources on the default distribution. To do this follow one of the options below.
+
+Configuration files are created in this order:
+
+1. Default AppDynamics configuration
+2. Buildpack default configuration is taken from `resources/app_dynamics_agent/default`
+3. External Configuration if configured
+4. Local Configuration if configured
+5. Buildpack Fork if it exists
+
+#### Buildpack Fork
+Add files to the `resources/app_dynamics_agent` directory in the buildpack fork. For example, to override the default `app-agent-config.xml` add your custom file to `resources/app_dynamics_agent//conf/app-agent-config.xml`.
+
+#### External Configuration
+Set `APPD_CONF_HTTP_URL` to an HTTP or HTTPS URL which points to the directory where your configuration files exist. You may also include a user and password in the URL, like `https://user:pass@example.com`.
+
+The Java buildpack will take the URL to the directory provided and attempt to download the following files from that directory:
+
+- `logging/log4j2.xml`
+- `logging/log4j.xml`
+- `app-agent-config.xml`
+- `controller-info.xml`
+- `service-endpoint.xml`
+- `transactions.xml`
+- `custom-interceptors.xml`
+- `custom-activity-correlation.xml`
+
+Any file successfully downloaded will be copied to the configuration directory. The buildpack does not fail if files are missing.
+
+#### Local Configuration
+Set `APPD_CONF_DIR` to a relative path which points to the directory in your application files where your custom configuration exists.
+
+The Java buildpack will take the `app_root` + `APPD_CONF_DIR` directory and attempt to copy the followinig files from that directory:
+
+- `logging/log4j2.xml`
+- `logging/log4j.xml`
+- `app-agent-config.xml`
+- `controller-info.xml`
+- `service-endpoint.xml`
+- `transactions.xml`
+- `custom-interceptors.xml`
+- `custom-activity-correlation.xml`
+
+Any files that exist will be copied to the configuration directory. The buildpack does not fail if files are missing.
+
[`config/app_dynamics_agent.yml`]: ../config/app_dynamics_agent.yml
+[AppDynamics Java Agent Configuration Properties]: https://docs.appdynamics.com/display/PRO42/Java+Agent+Configuration+Properties
[AppDynamics Service]: http://www.appdynamics.com
[Configuration and Extension]: ../README.md#configuration-and-extension
[repositories]: extending-repositories.md
-[this listing]: http://download.pivotal.io.s3.amazonaws.com/app-dynamics/index.yml
+[this listing]: https://packages.appdynamics.com/java/index.yml
[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-aspectj_weaver_agent.md b/docs/framework-aspectj_weaver_agent.md
new file mode 100644
index 0000000000..926315defe
--- /dev/null
+++ b/docs/framework-aspectj_weaver_agent.md
@@ -0,0 +1,26 @@
+# AspectJ Weaver Agent Framework
+The AspectJ Weaver Agent Framework configures the AspectJ Runtime Weaving Agent at runtime.
+
+
+
+ | Detection Criterion |
+ aspectjweaver-*.jar existing and BOOT-INF/classes/META-INF/aop.xml, BOOT-INF/classes/org/aspectj/aop.xml, META-INF/aop.xml, or org/aspectj/aop.xml existing. |
+
+
+ | Tags |
+ aspectj-weaver-agent=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by creating or modifying the [`config/aspectj_weaver_agent.yml`][] file in the buildpack fork.
+
+| Name | Description
+| ---- | -----------
+| `enabled` | Whether to enable the AspectJ Runtime Weaving agent.
+
+[`config/aspectj_weaver_agent.yml`]: ../config/aspect_weaver_agent.yml
+[Configuration and Extension]: ../README.md#configuration-and-extension
diff --git a/docs/framework-azure_application_insights_agent.md b/docs/framework-azure_application_insights_agent.md
new file mode 100644
index 0000000000..ec78d2c921
--- /dev/null
+++ b/docs/framework-azure_application_insights_agent.md
@@ -0,0 +1,33 @@
+# Azure Application Insights Agent Framework
+The Azure Application Insights Agent Framework causes an application to be automatically configured to work with a bound [Azure Application Insights Service][]. **Note:** This framework is disabled by default.
+
+
+
+ | Detection Criterion | Existence of a single bound Azure Application Insights service.
+
+ - Existence of a Azure Application Insights service is defined as the
VCAP_SERVICES payload containing a service who's name, label or tag has azure-application-insights as a substring with at least `connection_string` or `instrumentation_key` set as credentials.
+
+ |
+
+
+ | Tags |
+ azure-application-insights=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## User-Provided Service
+Users must provide their own Azure Application Insights service. A user-provided Azure Application Insights service must have a name or tag with `azure-application-insights` in it so that the Azure Application Insights Agent Framework Framework will automatically configure the application to work with the service.
+
+The credential payload of the service has to contain one of the following entries:
+
+| Name | Description
+| ---- | -----------
+| `connection_string` | With agent version 3.x the connection string is required. You can find your connection string in your Application Insights resource.
+| `instrumentation_key` | With agent version 2.x the instrumentation key is required. With version 3.x this configuration is deprecated an it is recommended to switch to a connection string. You can find your instrumentation key in your Application Insights resource.
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[Azure Application Insights Service]: https://learn.microsoft.com/en-us/azure/azure-monitor/app/java-in-process-agent
diff --git a/docs/framework-checkmarx_iast_agent.md b/docs/framework-checkmarx_iast_agent.md
new file mode 100644
index 0000000000..45a938def6
--- /dev/null
+++ b/docs/framework-checkmarx_iast_agent.md
@@ -0,0 +1,22 @@
+# Checkmarx IAST Agent Framework
+The Checkmarx IAST Agent Framework causes an application to be automatically configured to work with a bound [Checkmarx IAST Service][].
+
+
+
+ | Detection Criterion | Existence of a bound Checkmarx IAST service. The existence of an Checkmarx IAST service is defined by the VCAP_SERVICES payload containing a service named checkmarx-iast.
+ |
+
+
+
+## User-Provided Service
+When binding Checkmarx IAST using a user-provided service, it must have the name `checkmarx-iast` and the credential payload must include the following entry:
+
+| Name | Description
+| ---- | -----------
+| `server` | The IAST Manager URL
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+[Checkmarx IAST Service]: https://www.checkmarx.com/products/interactive-application-security-testing
+[Configuration and Extension]: ../README.md#configuration-and-extension
diff --git a/docs/framework-client_certificate_mapper.md b/docs/framework-client_certificate_mapper.md
new file mode 100644
index 0000000000..5d3852b5a6
--- /dev/null
+++ b/docs/framework-client_certificate_mapper.md
@@ -0,0 +1,37 @@
+# Client Certificate Mapper
+The Client Certificate Mapper Framework adds a Servlet Filter to applications that will that maps the `X-Forwarded-Client-Cert` to the `javax|jakarta.servlet.request.X509Certificate` Servlet attribute.
+
+The Client Certificate Mapper Framework will download a helper library, [java-buildpack-client-certificate-mapper][library repository], that will enrich Spring Boot (2 and 3), as well as JEE / JakartaEE applications classpath with a servlet filter.
+
+
+
+ | Detection Criterion |
+ Unconditional |
+
+
+ | Tags |
+ client-certificate-mapper=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by modifying the [`config/client_certificate_mapper.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+
+| Name | Description
+|-------------------| -----------
+| `repository_root` | The URL of the Container Customizer repository index ([details][repositories]).
+| `version` | The version of Container Customizer to use. Candidate versions can be found in [this listing][].
+
+## Servlet Filter
+The [Servlet Filter][] added by this framework maps the `X-Forwarded-Client-Cert` to the `javax.servlet.request.X509Certificate` Servlet attribute for each request. The `X-Forwarded-Client-Cert` header is contributed by the Cloud Foundry Router and contains the any TLS certificate presented by a client for mututal TLS authentication. This certificate can then be used by any standard Java security framework to establish authentication and authorization for a request.
+
+[`config/client_certificate_mapper.yml`]: ../config/client_certificate_mapper.yml
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[repositories]: extending-repositories.md
+[Servlet Filter]: https://github.com/cloudfoundry/java-buildpack-client-certificate-mapper
+[this listing]: http://download.pivotal.io.s3.amazonaws.com/container-security-provider/index.yml
+[version syntax]: extending-repositories.md#version-syntax-and-ordering
+[library repository]: https://github.com:cloudfoundry/java-buildpack-client-certificate-mapper.git
diff --git a/docs/framework-container_customizer.md b/docs/framework-container_customizer.md
new file mode 100644
index 0000000000..97538ea05e
--- /dev/null
+++ b/docs/framework-container_customizer.md
@@ -0,0 +1,30 @@
+# Container Customizer Framework
+The Container Customizer Framework modifies the configuration of an embedded Tomcat container in a Spring Boot WAR file.
+
+
+
+ | Detection Criterion |
+ Application is a Spring Boot WAR file |
+
+
+ | Tags |
+ container-customizer=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by modifying the [`config/container_customizer.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+
+| Name | Description
+| ---- | -----------
+| `repository_root` | The URL of the Container Customizer repository index ([details][repositories]).
+| `version` | The version of Container Customizer to use. Candidate versions can be found in [this listing][].
+
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[`config/container_customizer.yml`]: ../config/container_customizer.yml
+[repositories]: extending-repositories.md
+[this listing]: http://download.pivotal.io.s3.amazonaws.com/container-customizer/index.yml
+[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-container_security_provider.md b/docs/framework-container_security_provider.md
new file mode 100644
index 0000000000..bb5f7c4223
--- /dev/null
+++ b/docs/framework-container_security_provider.md
@@ -0,0 +1,39 @@
+# Container Security Provider
+The Container Security Provider Framework adds a Security Provider to the JVM that automatically includes BOSH trusted certificates and Diego identity certificates and private keys.
+
+
+
+ | Detection Criterion |
+ Unconditional |
+
+
+ | Tags |
+ container-security-provider=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by modifying the [`config/container_security_provider.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+
+| Name | Description
+| ---- | -----------
+| `repository_root` | The URL of the Container Customizer repository index ([details][repositories]).
+| `version` | The version of Container Customizer to use. Candidate versions can be found in [this listing][].
+| `key_manager_enabled` | Whether the container `KeyManager` is enabled. Defaults to `true`.
+| `trust_manager_enabled` | Whether the container `TrustManager` is enabled. Defaults to `true`.
+
+## Security Provider
+The [security provider][] added by this framework contributes two types, a `TrustManagerFactory` and a `KeyManagerFactory`. The `TrustManagerFactory` adds an additional new `TrustManager` after the configured system `TrustManager` which reads the contents of `/etc/ssl/certs/ca-certificates.crt` which is where [BOSH trusted certificates][] are placed. The `KeyManagerFactory` adds an additional `KeyManager` after the configured system `KeyManager` which reads the contents of the files specified by `$CF_INSTANCE_CERT` and `$CF_INSTANCE_KEY` which are set by Diego to give each container a unique cryptographic identity. These `TrustManager`s and `KeyManager`s are used transparently by any networking library that reads standard system SSL configuration and can be used to enable system-wide trust and [mutual TLS authentication][].
+
+
+[`config/container_security_provider.yml`]: ../config/container_security_provider.yml
+[BOSH trusted certificates]: https://bosh.io/docs/trusted-certs.html
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[mutual TLS authentication]: https://en.wikipedia.org/wiki/Mutual_authentication
+[repositories]: extending-repositories.md
+[security provider]: https://github.com/cloudfoundry/java-buildpack-security-provider
+[this listing]: http://download.pivotal.io.s3.amazonaws.com/container-security-provider/index.yml
+[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-contrast_security_agent.md b/docs/framework-contrast_security_agent.md
new file mode 100644
index 0000000000..ab6e5d4ea0
--- /dev/null
+++ b/docs/framework-contrast_security_agent.md
@@ -0,0 +1,39 @@
+# Contrast Security Agent Framework
+The Contrast Security Agent Framework causes an application to be automatically configured to work with a bound [Contrast Security Service][].
+
+
+
+ | Detection Criterion | Existence of a single bound Contrast Security service. The existence of an Contrast Security service defined by the VCAP_SERVICES payload containing a service name, label or tag with contrast-security as a substring.
+ |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## User-Provided Service
+When binding ContrastSecurity using a user-provided service, it must have name or tag with `contrast-security` in it. The credential payload can contain the following entries:
+
+| Name | Description
+| ---- | -----------
+| `api_key` | Your user's api key
+| `service_key` | Your user's service key
+| `teamserver_url` | The base URL in which your user has access to and the URL to which the Agent will report. ex: https://app.contrastsecurity.com
+| `username` | The account name to use when downloading the agent
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by modifying the [`config/contrast_security_agent.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+
+| Name | Description
+| ---- | -----------
+| `repository_root` | The URL of the Contrast Security repository index ([details][repositories]).
+| `version` | The version of Contrast Security to use. Candidate versions can be found in [this listing][].
+
+[Contrast Security]: https://www.contrastsecurity.com
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[Contrast Security Service]: https://www.contrastsecurity.com
+[`config/contrast_security_agent.yml`]: ../config/contrast_security_agent.yml
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[repositories]: extending-repositories.md
+[this listing]: https://artifacts.contrastsecurity.com/agents/java/index.yml
+[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-datadog_javaagent.md b/docs/framework-datadog_javaagent.md
new file mode 100644
index 0000000000..b5efa52f37
--- /dev/null
+++ b/docs/framework-datadog_javaagent.md
@@ -0,0 +1,46 @@
+# Datadog APM Javaagent Framework
+The [Datadog APM]() Javaagent Framework installs an agent that allows your application to be dynamically instrumented [by][datadog-javaagent] `dd-java-agent.jar`.
+
+For this functionality to work, you **must** also use this feature in combination with the [Datadog Cloudfoundry Buildpack](). The Datadog Cloudfoundry Buildpack **must** run first, so that it can supply the components to which the Datadog APM agent will talk. Please make sure you follow the instructions on the README for the Datadog Cloudfoundry Buildpack to enable and configure it.
+
+The framework will configure the Datadog agent for correct use in most situations, however you may adjust its behavior by setting additional environment variables. For a complete list of Datadog Agent configuration options, please see the [Datadog Documentation](https://docs.datadoghq.com/tracing/setup_overview/setup/java/?tab=containers#configuration).
+
+
+
+ | Detection Criterion | All must be true:
+
+ - The Datadog Buildpack must be included
+ DD_API_KEY defined and contain your API key
+
+ Optionally, you may set DD_APM_ENABLED to false to force the framework to not contribute the agent.
+ |
+
+
+ | Tags |
+ datadog-javaagent=<version> |
+
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+
+The javaagent can be configured directly via environment variables or system properties as defined in the [Configuration of Datadog Javaagent][] documentation.
+
+
+| Name | Description
+| ---- | -----------
+| `repository_root` | The URL of the Datadog Javaagent repository index ([details][repositories]).
+| `version` | The `dd-java-agent` version to use. Candidate versions can be found in [this listing][].
+
+
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[Datadog APM]: https://www.datadoghq.com/product/apm/
+[Datadog Cloudfoundry Builpack]: https://github.com/DataDog/datadog-cloudfoundry-buildpack
+[datadog-javaagent]: https://github.com/datadog/dd-trace-java
+[Configuration of Datadog Javaagent]: https://docs.datadoghq.com/tracing/setup_overview/setup/java/#configuration
+[this listing]: https://raw.githubusercontent.com/datadog/dd-trace-java/cloudfoundry/index.yml
+[repositories]: extending-repositories.md
+[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-debug-eclipse.png b/docs/framework-debug-eclipse.png
new file mode 100644
index 0000000000..e01c28d329
Binary files /dev/null and b/docs/framework-debug-eclipse.png differ
diff --git a/docs/framework-debug.md b/docs/framework-debug.md
new file mode 100644
index 0000000000..303ce3fe2b
--- /dev/null
+++ b/docs/framework-debug.md
@@ -0,0 +1,41 @@
+# Debug Framework
+The Debug Framework contributes Java debug configuration to the application at runtime. **Note:** This framework is only useful in Diego-based containers with SSH access enabled.
+
+
+
+ | Detection Criterion |
+ enabled set in the config/debug.yml file |
+
+
+ | Tags |
+ debug=<port> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by creating or modifying the [`config/debug.yml`][] file in the buildpack fork.
+
+| Name | Description
+| ---- | -----------
+| `enabled` | Whether to enable Java debugging
+| `port` | The port that the debug agent will listen on. Defaults to `8000`.
+| `suspend` | Whether to suspend execution until a debugger has attached. Note, you cannot ssh to a container until the container has decided the application is running. Therefore when enabling this setting you must also push the application using the parameter `-u process` which disables container health checking.
+
+## Creating SSH Tunnel
+After starting an application with debugging enabled, an SSH tunnel must be created to the container. To create that SSH container, execute the following command:
+
+```bash
+$ cf ssh -N -T -L :localhost:
+```
+
+The `REMOTE_PORT` should match the `port` configuration for the application (`8000` by default). The `LOCAL_PORT` can be any open port on your computer, but typically matches the `REMOTE_PORT` where possible.
+
+Once the SSH tunnel has been created, your IDE should connect to `localhost:` for debugging.
+
+
+
+[`config/debug.yml`]: ../config/debug.yml
+[Configuration and Extension]: ../README.md#configuration-and-extension
diff --git a/docs/framework-dynatrace_one_agent.md b/docs/framework-dynatrace_one_agent.md
new file mode 100644
index 0000000000..0cbeaf3866
--- /dev/null
+++ b/docs/framework-dynatrace_one_agent.md
@@ -0,0 +1,43 @@
+# Dynatrace SaaS/Managed OneAgent Framework
+[Dynatrace SaaS/Managed](http://www.dynatrace.com/cloud-foundry/) is your full stack monitoring solution - powered by artificial intelligence. Dynatrace SaaS/Managed allows you insights into all application requests from the users click in the browser down to the database statement and code-level.
+
+The Dynatrace SaaS/Managed OneAgent Framework causes an application to be automatically configured to work with a bound [Dynatrace SaaS/Managed Service][] instance (Free trials available).
+
+
+
+ | Detection Criterion | Existence of a single bound Dynatrace SaaS/Managed service.
+
+ - Existence of a Dynatrace SaaS/Managed service is defined as the
VCAP_SERVICES payload containing a service who's name, label or tag has dynatrace as a substring with at least `environmentid` and `apitoken` set as credentials.
+
+ |
+
+
+ | Tags |
+ dynatrace-one-agent=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## User-Provided Service
+Users must provide their own Dynatrace SaaS/Managed service. A user-provided Dynatrace SaaS/Managed service must have a name or tag with `dynatrace` in it so that the Dynatrace Saas/Managed OneAgent Framework will automatically configure the application to work with the service.
+
+The credential payload of the service may contain the following entries:
+
+| Name | Description
+| ---- | -----------
+| `apitoken` | The token for integrating your Dynatrace environment with Cloud Foundry. You can find it in the deploy Dynatrace section within your environment.
+| `apiurl` | (Optional) The base URL of the Dynatrace API. If you are using Dynatrace Managed you will need to set this property to `https:///e//api`. If you are using Dynatrace SaaS you don't need to set this property.
+| `environmentid` | Your Dynatrace environment ID is the unique identifier of your Dynatrace environment. You can find it in the deploy Dynatrace section within your environment.
+| `networkzone` | (Optional) Network zones are Dynatrace entities that represent your network structure. They help you to route the traffic efficiently, avoiding unnecessary traffic across data centers and network regions. Enter the network zone you wish to pass to the server during the OneAgent Download.
+| `skiperrors` | (Optional) The errors during agent download are skipped and the injection is disabled. Use this option at your own risk. Possible values are 'true' and 'false'. This option is disabled by default!
+| `enablefips`| (Optional) Enables the use of [FIPS 140 cryptographic algorithms](https://docs.dynatrace.com/docs/shortlink/oneagentctl#fips-140). Possible values are 'true' and 'false'. This option is disabled by default!
+| addtechnologies | (Optional) Adds additional OneAgent code-modules via a comma-separated list. See [supported values](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/deployment/oneagent/download-oneagent-version#parameters) in the "included" row|
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+## Support
+This buildpack extension is currently Beta. If you have any questions or problems regarding the build pack itself please don't hesitate to contact Dynatrace on https://answers.ruxit.com/, be sure to use "cloudfoundry" as a topic.
+
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[Dynatrace SaaS/Managed Service]: http://www.dynatrace.com/cloud-foundry/
diff --git a/docs/framework-elastic_apm_agent.md b/docs/framework-elastic_apm_agent.md
new file mode 100644
index 0000000000..55f09c5d15
--- /dev/null
+++ b/docs/framework-elastic_apm_agent.md
@@ -0,0 +1,67 @@
+# Elastic APM Agent Framework
+
+The Elastic APM Agent Framework causes an application to be automatically configured to work with [Elastic APM][].
+
+
+
+ | Detection Criterion |
+ Existence of a single bound Elastic APM service. The existence of an Elastic APM service defined by the VCAP_SERVICES payload containing a service name, label or tag with elastic-apm as a substring.
+ |
+
+ | Tags |
+ elastic-apm-agent=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## User-Provided Service
+When binding Elastic APM using a user-provided service, it must have name or tag with `elasticapm` or `elastic-apm` in it. The credential payload can contain the following entries.
+
+| Name | Description
+| ---- | -----------
+| `server_urls` | The URLs for the Elastic APM Server. They must be fully qualified, including protocol (http or https) and port.
+| `secret_token` (Optional)| This string is used to ensure that only your agents can send data to your APM server. Both the agents and the APM server have to be configured with the same secret token. Use if APM Server requires a token.
+| `***` (Optional) | Any additional entries will be applied as a system property appended to `-Delastic.apm.` to allow full configuration of the agent. See [Configuration of Elastic Agent][]. Values are shell-escaped by default, but do have limited support, use with caution, for incorporating subshells (i.e. `$(some-cmd)`) and accessing environment variables (i.e. `${SOME_VAR}`).
+
+
+### Creating an Elastic APM USer Provided Service
+Users must provide their own Elastic APM service. A user-provided Elastic APM service must have a name or tag with `elastic-apm` in it so that the Elastic APM Agent Framework will automatically configure the application to work with the service.
+
+Example of a minimal configuration:
+
+```
+cf cups my-elastic-apm-service -p '{"server_urls":"https://my-apm-server:8200","secret_token":"my-secret-token"}'
+```
+
+Example of a configuration with additional configuration parameters:
+
+```
+cf cups my-elastic-apm-service -p '{"server_urls":"https://my-apm-server:8200","secret_token":"","server_timeout":"10s","environment":"production"}'
+```
+
+Bind your application to the service using:
+
+`cf bind-service my-app-name my-elastic-apm-service`
+
+or use the `services` block in the application manifest file.
+
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by modifying the [`config/elastic_apm_agent.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+
+| Name | Description
+| ---- | -----------
+| `service_name` | This can be overridden by a `service_name` entry in the credentials payload. If neither are supplied the default is the application_name as specified by Cloud Foundry.
+| `repository_root` | The URL of the Elastic APM repository index ([details][repositories]).
+| `version` | The version of Elastic APM to use. Candidate versions can be found in [this listing][].
+
+
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[`config/elastic_apm_agent.yml`]: ../config/elastic_apm_agent.yml
+[Elastic APM]: https://www.elastic.co/guide/en/apm/agent/java/current/index.html
+[repositories]: extending-repositories.md
+[this listing]: https://raw.githubusercontent.com/elastic/apm-agent-java/master/cloudfoundry/index.yml
+[version syntax]: extending-repositories.md#version-syntax-and-ordering
+[Configuration of Elastic Agent]: https://www.elastic.co/guide/en/apm/agent/java/current/configuration.html
diff --git a/docs/framework-google_stackdriver_debugger.md b/docs/framework-google_stackdriver_debugger.md
new file mode 100644
index 0000000000..82d1a4b991
--- /dev/null
+++ b/docs/framework-google_stackdriver_debugger.md
@@ -0,0 +1,43 @@
+# Google Stackdriver Debugger Framework
+The Google Stackdriver Debugger Framework causes an application to be automatically configured to work with a bound [Google Stackdriver Debugger Service][].
+
+
+
+ | Detection Criterion | Existence of a single bound Google Stackdriver Debugger service.
+
+ - Existence of a Google Stackdriver Debugger service is defined as the
VCAP_SERVICES payload containing a service who's name, label or tag has google-stackdriver-debugger as a substring.
+
+ |
+
+
+ | Tags |
+ google-stackdriver-debugger=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## User-Provided Service (Optional)
+Users may optionally provide their own Google Stackdriver Debugger service. A user-provided Google Stackdriver Debugger service must have a name or tag with `google-stackdriver-debugger` in it so that the Google Stackdriver Debugger Agent Framework will automatically configure the application to work with the service.
+
+The credential payload of the service must contain the following entry:
+
+| Name | Description
+| ---- | -----------
+| `PrivateKeyData` | A Base64 encoded Service Account JSON payload
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by modifying the [`config/google_stackdriver_debugger.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+
+| Name | Description
+| ---- | -----------
+| `repository_root` | The URL of the Google Stackdriver Debugger repository index ([details][repositories]).
+| `version` | The version of Google Stackdriver Debugger to use. Candidate versions can be found in [this listing][].
+
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[`config/google_stackdriver_debugger.yml`]: ../config/google_stackdriver_debugger.yml
+[Google Stackdriver Debugger Service]: https://cloud.google.com/debugger/
+[repositories]: extending-repositories.md
+[this listing]: https://java-buildpack.cloudfoundry.org/google-stackdriver-debugger/jammy/x86_64/index.yml
+[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-google_stackdriver_profiler.md b/docs/framework-google_stackdriver_profiler.md
new file mode 100644
index 0000000000..7bc3fa645f
--- /dev/null
+++ b/docs/framework-google_stackdriver_profiler.md
@@ -0,0 +1,43 @@
+# Google Stackdriver Profiler Framework
+The Google Stackdriver Profiler Framework causes an application to be automatically configured to work with a bound [Google Stackdriver Profiler Service][].
+
+
+
+ | Detection Criterion | Existence of a single bound Google Stackdriver Profiler service.
+
+ - Existence of a Google Stackdriver Profiler service is defined as the
VCAP_SERVICES payload containing a service who's name, label or tag has google-stackdriver-profiler as a substring.
+
+ |
+
+
+ | Tags |
+ google-stackdriver-profiler=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## User-Provided Service (Optional)
+Users may optionally provide their own Google Stackdriver Profiler service. A user-provided Google Stackdriver Profiler service must have a name or tag with `google-stackdriver-profiler` in it so that the Google Stackdriver Profiler Agent Framework will automatically configure the application to work with the service.
+
+The credential payload of the service must contain the following entry:
+
+| Name | Description
+| ---- | -----------
+| `PrivateKeyData` | A Base64 encoded Service Account JSON payload
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by modifying the [`config/google_stackdriver_profiler.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+
+| Name | Description
+| ---- | -----------
+| `repository_root` | The URL of the Google Stackdriver Profiler repository index ([details][repositories]).
+| `version` | The version of Google Stackdriver Profiler to use. Candidate versions can be found in [this listing][].
+
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[`config/google_stackdriver_profiler.yml`]: ../config/google_stackdriver_profiler.yml
+[Google Stackdriver Profiler Service]: https://cloud.google.com/profiler/
+[repositories]: extending-repositories.md
+[this listing]: https://java-buildpack.cloudfoundry.org/google-stackdriver-profiler/jammy/x86_64/index.yml
+[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-introscope_agent.md b/docs/framework-introscope_agent.md
new file mode 100644
index 0000000000..d63adaeb24
--- /dev/null
+++ b/docs/framework-introscope_agent.md
@@ -0,0 +1,79 @@
+# CA Introscope APM Framework
+The CA Introscope APM Framework causes an application to be automatically configured to work with a bound [Introscope service][].
+
+
+
+ | Detection Criterion | Existence of a single bound Introscope service.
+
+ - Existence of a Introscope service is defined as the
VCAP_SERVICES payload containing a service who's name, label or tag has introscope as a substring.
+
+ |
+
+
+ | Tags |
+ introscope-agent=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## User-Provided Service (Optional)
+Users may optionally provide their own Introscope service. A user-provided Introscope service must have a name or tag with `introscope` in it so that the Introscope Agent Framework will automatically configure the application to work with the service.
+
+The credential payload of the service may contain any valid CA APM Java agent property.
+
+The table below displays a subset of properties that are accepted by the buildpack.
+Please refer to CA APM docs for a full list of valid agent properties.
+
+
+| Name | Description
+| ---- | -----------
+|`agent_manager_credential`| (Optional) The credential that is used to connect to the Enterprise Manager server.
+|`agentManager_url_1` | The url of the Enterprise Manager server.
+|`agent_manager_url`| (Deprecated) The url of the Enterprise Manager server.
+|`credential`| (Deprecated) The credential that is used to connect to the Enterprise Manager server
+
+
+To provide more complex values such as the `agent_name`, using the interactive mode when creating a user-provided service will manage the character escaping automatically. For example, the default `agent_name` could be set with a value of `agent-$(expr "$VCAP_APPLICATION" : '.*application_name[": ]*\([[:word:]]*\).*')` to calculate a value from the Cloud Foundry application name.
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by modifying the [`config/introscope_agent.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+
+| Name | Description
+| ---- | -----------
+| `repository_root` | The URL of the Introscope Agent repository index ([details][repositories]).
+| `version` | The version of Introscope Agent to use.
+
+### Additional Resources
+The framework can also be configured by overlaying a set of resources on the default distribution. To do this, add files to the `resources/introscope_agent` directory in the buildpack fork.
+
+##### Example for 10.x
+```
+resources/
+ |-introscope_agent/
+ |-core/
+ |-config/
+ |-IntroscopeAgent.profile # place custom Introscope Profile under the config folder
+ |-hotdeploy/ # place custom pbd files under the hotdeploy folder
+ |-example.pbd
+```
+
+##### Example for 11.1.x
+```
+resources/
+ |-introscope_agent/
+ |-releases/
+ |-11.1/
+ |-core/
+ |-config/
+ |-IntroscopeAgent.profile # place custom Introscope Profile under the config folder
+ |-hotdeploy/ # place custom pbd files under the hotdeploy folder
+ |-example.pbd
+```
+
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[`config/intoscope_agent.yml`]: ../config/intoscope_agent.yml
+[Introscope service]: http://www.ca.com/us/opscenter/ca-application-performance-management.aspx
+[repositories]: extending-repositories.md
+[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-jacoco_agent.md b/docs/framework-jacoco_agent.md
new file mode 100644
index 0000000000..c97d75e08a
--- /dev/null
+++ b/docs/framework-jacoco_agent.md
@@ -0,0 +1,50 @@
+# JaCoco Agent Framework
+The JaCoCo Agent Framework causes an application to be automatically configured to work with a bound [JaCoCo Service][].
+
+
+
+ | Detection Criterion | Existence of a single bound JaCoCo service.
+
+ - Existence of a JaCoCo service is defined as the
VCAP_SERVICES payload containing a service who's name, label or tag has jacoco as a substring.
+
+ |
+
+
+ | Tags |
+ jacoco-agent=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## User-Provided Service (Optional)
+Users may optionally provide their own JaCoCo service. A user-provided JaCoCo service must have a name or tag with `jacoco` in it so that the JaCoCo Agent Framework will automatically configure the application to work with the service.
+
+The credential payload of the service may contain the following entries:
+
+| Name | Description
+| ---- | -----------
+| `address` | The host for the agent to connect to or listen on
+| `excludes` | (Optional) A list of class names that should be excluded from execution analysis. The list entries are separated by a colon (:) and may use wildcard characters (* and ?).
+| `includes` | (Optional) A list of class names that should be included in execution analysis. The list entries are separated by a colon (:) and may use wildcard characters (* and ?).
+| `port` | (Optional) The port for the agent to connect to or listen on
+| `output` | (Optional) The mode for the agent. Possible values are either tcpclient (default) or tcpserver.
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by modifying the [`config/jacoc_agent.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+
+| Name | Description
+| ---- | -----------
+| `repository_root` | The URL of the JaCoCo repository index ([details][repositories]).
+| `version` | The version of JaCoCo to use. Candidate versions can be found in [this listing][].
+
+### Additional Resources
+The framework can also be configured by overlaying a set of resources on the default distribution. To do this, add files to the `resources/jacoco_agent` directory in the buildpack fork. For example, to override the default `jacoco.yml` add your custom file to `resources/jacoco_agent/jacoco.yml`.
+
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[`config/jacoco_agent.yml`]: ../config/jacoco_agent.yml
+[JaCoCo Service]: http://www.jacoco.org/jacoco/
+[repositories]: extending-repositories.md
+[this listing]: https://java-buildpack.cloudfoundry.org/jacoco/index.yml
+[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-java-cfenv.md b/docs/framework-java-cfenv.md
new file mode 100644
index 0000000000..e9bbb31c71
--- /dev/null
+++ b/docs/framework-java-cfenv.md
@@ -0,0 +1,19 @@
+# Java CfEnv Framework
+The Java CfEnv Framework provides the `java-cfenv` library for Spring Boot 3+ applications. This library sets various Spring Boot properties by parsing CloudFoundry variables such as `VCAP_SERVICES`, allowing Spring Boot's autoconfiguration to kick in.
+
+This is the recommended replacement for Spring AutoReconfiguration library which is deprecated. See the `java-cfenv` repostitory for more detail.
+
+It also sets the 'cloud' profile for Spring Boot applications, as the Spring AutoReconfiguration framework did.
+
+
+
+ | Detection Criterion |
+ Existence of a `Spring-Boot-Version: 3.*` manifest entry |
+ No existing `java-cfenv` library found |
+
+
+ | Tags |
+ java-cf-env=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
diff --git a/docs/framework-java_memory_assistant.md b/docs/framework-java_memory_assistant.md
new file mode 100644
index 0000000000..f8a2f60594
--- /dev/null
+++ b/docs/framework-java_memory_assistant.md
@@ -0,0 +1,125 @@
+# Java Memory Assistant Framework
+The Java Memory Assistant is a Java agent (as in `-javaagent`) that creats heap dumps of your application automatically based on preconfigured conditions of memory usage.
+The heap dumps created by the Java Memory Assistant can be analyzed using Java memory profilers that support the `.hprof` format (i.e., virtually all profilers).
+
+
+
+ | Detection Criterion | enabled set in the config/java_memory_assistant.yml |
+
+
+ | Tags | java-memory-assistant=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script.
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by modifying the [`config/java_memory_assistant.yml`][] file in the buildpack fork.
+
+| Name | Description
+| ---- | -----------
+| `enabled` | Whether to enable the Java Memory Assistant framework. By default the agent is turned off.
+| `agent.heap_dump_folder` | The folder on the container's filesystem where heap dumps are created. Default value: `$PWD`
+| `agent.thresholds.` | This configuration allows to define thresholds for every memory area of the JVM. Thresholds can be defined in absolute percentages, e.g., `75%` creates a heap dump at 75% of the selected memory area. It is also possible to specify relative increases and decreases of memory usage: for example, `+5%/2m` will triggera heap dumpo if the particular memory area has increased by `5%` or more over the last two minutes. See below to check which memory areas are supported. Since version `0.3.0`, thresholds can also be specified in terms of absolute values, e.g., `>400MB` (more than 400 MB) or `<=30KB` (30 KB or less); supported memory size units are `KB`, `MB` and `GB`.
+| `agent.check_interval` | The interval between checks. Examples: `1s` (once a second), `3m` (every three minutes), `1h` (once every hour). Default: `5s` (check every five seconds).
+| `agent.max_frequency` | Maximum amount of heap dumps that the Java Memory Assistant is allowed to create in a given amount of time. Examples: `1/30s` (no more than one heap dump every thirty seconds), `2/3m` (up to two heap dumps every three minutes), `1/2h` (one heap dump every two hours). The time interval is checked every time one heap dump *should* be created (based on the specified thresholds), and compared with the timestamps of the previously created heap dumps to make sure that the maximum frequency is not exceeded. Default: `1/1m` (one heap dump per minute). |
+| `agent.log_level` | The log level used by the Java Memory Assistant. Supported values are the same as the Java buildpack's: `DEBUG`, `WARN`, `INFO`, `ERROR` and `FATAL` (the latter is equivalent to `ERROR`). If the `agent.log_level` is not specified, the Java buildpack's log level will be used. |
+| `clean_up.max_dump_count` | Maximum amount of heap dumps that can be stored in the filesystem of the container; when the creation of a new heap dump would cause the threshold to be surpassed, the oldest heap dumps are removed from the file system. Default value: `1` |
+
+### Heap Dump Names
+
+The heap dump filenames will be generated according to the following name pattern:
+
+`-%ts:yyyyMMdd'T'mmssSSSZ%-.hprof`
+
+The timestamp pattern `%ts:yyyyMMdd'T'mmssSSSZ%` is equivalent to the `%FT%T%z` pattern of [strftime](http://www.cplusplus.com/reference/ctime/strftime/) for [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601). The default naming convention matches the [`jvmkill`][] naming convention.
+
+### Supported Memory Areas
+
+| Memory Area | Property Name |
+|------------------------|------------------|
+| Heap | `heap` |
+| Code Cache | `code_cache` |
+| Metaspace | `metaspace` |
+| Compressed Class Space | `compressed_class` |
+| Eden | `eden` |
+| Survivor | `survivor` |
+| Old Generation | `old_gen` |
+| Tenured Gen | `tenured_gen` |
+| CodeHeap 'non-nmethods' | `code_heap.non_nmethods` |
+| CodeHeap 'profiled nmethods' | `code_heap.profiled_nmethods` |
+| CodeHeap 'non-profiled nmethods' | `code_heap.non_profiled_nmethods` |
+
+Different builds and versions of Java Virtual Machines offer different memory areas.
+The list of supported Java Virtual Machines and the respective memory areas can be found in the [Java Memory Assistant documentation](https://github.com/SAP/java-memory-assistant#supported-jvms).
+
+The default values can be found in the [`config/java_memory_assistant.yml`][] file.
+
+### Examples
+
+Enable the Java Memory Assistant with its default settings:
+
+```yaml
+JBP_CONFIG_JAVA_MEMORY_ASSISTANT: '{enabled : true}'
+```
+
+Create heap dumps when the old generation memory pool exceeds 800 MB:
+
+```yaml
+JBP_CONFIG_JAVA_MEMORY_ASSISTANT: '{enabled : true, agent: { thresholds : { old_gen : ">800MB" } } }'
+```
+
+Create heap dumps when the old generation grows by more than 20% in two minutes:
+
+```yaml
+JBP_CONFIG_JAVA_MEMORY_ASSISTANT: '{enabled : true, agent : { thresholds : { old_gen : +20%/2m } } }'
+```
+
+### What are the right thresholds for your application?
+
+Well, it depends.
+The way applications behave in terms of memory management is a direct result of how they are implemented.
+This is much more then case when the applications are under heavy load.
+Thus, there is no "silver bullet" configuration that will serve all applications equally well, and Java Memory Assistant configurations should result from profiling the application under load and then encode the expected memory usage patterns (plus a margin upwards) to detect anomalies.
+
+Nevertheless, a memory area that tends to be particularly interesting to monitor is the so called "old generation" (`old_gen`).
+When instantiated, bjects in the Java heap are allocated in an area called `eden`.
+As garbage collections occur, objects that are not reclaimed become first "survivors" (and belong to the namesake `survivor` memory area) and then eventually become `old_gen`.
+In other words, `old_gen` objects are those that survived multiple garbage collections.
+In contrast, `eden` and `survivor` objects are collectively called "young generation".
+
+Application-wide singletons and pooled objects (threads, connections) are examples of "legitimate" `old_gen` candidates.
+But memory leaks, by their very nature or surviving multiple garbage collections, end up in `old_gen` too.
+Under load that is not too high for the application (and you should find out what it is with load tests and avoid it via rate limiting, e.g., using [route services](https://docs.cloudfoundry.org/services/route-services.html) in front of your application), Java code that allows the JVM to perform efficient memory management tends to have a rather consistent baseline of `old_gen` objects, with most objects being reclaimed as they are still young generation.
+That is, when the `old_gen` grows large with respect to the overall heap, this often signifies some sort of memory leak or, at the very least, suboptimal memory management.
+Notable exceptions to this rule of thumb are applications that use large local caches.
+
+### Making sure heap dumps can be created
+
+The Java Virtual Machine must create heap dumps on a file.
+Unless you are using a `volume service`, it pretty much means that, even if you are uploading the heap dump somewhere else, the heap dump must first land on the ephemeral disk of the container.
+Ephemeral disks have quotas and, if all the space is taken by heap dumps (even incomplete ones!), horrible things are bound to happen to your app.
+
+The maximum size of a heap dump depends on the maximum size of the heap of the Java Virtual Machine.
+Consider increasing the disk quota of your warden/garden container via the `cf scale -k [new size]` using as `new size` to the outcome of the following calculation:
+
+`[max heap size] * [max heap dump count] + 200MB`
+
+The aditional `200MB` is a rule-of-thumb, generous over-approximation of the amount of disk the buildpack and the application therein needs to run.
+If your application requires more filesystem than just a few tens of megabytes, you must increase the additional portion of the disk amount calculation accordingly.
+
+### Where to best store heap dumps?
+
+Heap dumps are created by the Java Virtual Machine on a file on the filesystem mounted by the garden container.
+Normally, the filesystem of a container is ephemeral.
+That is, if your app crashes or it is shut down, the filesystem of its container is gone with it and so are your heap dumps.
+
+To prevent heap dumps from "going down" with the container, you should consider storing them on a `volume service`.
+
+#### Container-mounted volumes
+
+If you are using a filesystem service that mounts persistent volumes to the container, it is enough to name one of the volume services `heap-dump` or tag one volume with `heap-dump`, and the path specified as the `heap_dump_folder` configuration will be resolved against `/-/-`. The default directory convention matches the [`jvmkill`][] directory convention.
+
+[`config/java_memory_assistant.yml`]: ../config/java_memory_assistant.yml
+[`jvmkill`]: jre-open_jdk_jre.md#jvmkill
diff --git a/docs/framework-java_opts.md b/docs/framework-java_opts.md
index 02e8237761..69dea716d6 100644
--- a/docs/framework-java_opts.md
+++ b/docs/framework-java_opts.md
@@ -14,9 +14,8 @@ The Java Options Framework contributes arbitrary Java options to the application
Tags are printed to standard output by the buildpack detect script
-
## Configuration
-For general information on configuring the buildpack, refer to [Configuration and Extension][].
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
The framework can be configured by creating or modifying the [`config/java_opts.yml`][] file in the buildpack fork.
@@ -25,7 +24,38 @@ The framework can be configured by creating or modifying the [`config/java_opts.
| `from_environment` | Whether to append the value of the `JAVA_OPTS` environment variable to the collection of Java options
| `java_opts` | The Java options to use when running the application. All values are used without modification when invoking the JVM. The options are specified as a single YAML scalar in plain style or enclosed in single or double quotes.
-Any `JAVA_OPTS` from either the config file or environment variables that configure memory options will cause deployment to fail as they're not allowed. Memory options are configured by the buildpack and may not be modified.
+Any `JAVA_OPTS` from either the config file or environment variables will be specified in the start command after any Java Opts added by other frameworks.
+
+## Escaping strings
+
+Java options will have special characters escaped when used in the shell command that starts the Java application but the `$` and `\` characters will not be escaped. This is to allow Java options to include environment variables when the application starts.
+
+```bash
+cf set-env my-application JAVA_OPTS '-Dexample.port=$PORT'
+```
+
+If an escaped `$` or `\` character is needed in the Java options they will have to be escaped manually. For example, to obtain this output in the start command.
+
+```bash
+-Dexample.other=something.\$dollar.\\slash
+```
+
+From the command line use;
+```bash
+cf set-env my-application JAVA_OPTS '-Dexample.other=something.\\\\\$dollar.\\\\\\\slash'
+```
+
+From the [`config/java_opts.yml`][] file use;
+```yaml
+from_environment: true
+java_opts: '-Dexample.other=something.\\$dollar.\\\\slash'
+```
+
+Finally, from the applications manifest use;
+```yaml
+ env:
+ JAVA_OPTS: '-Dexample.other=something.\\\\\$dollar.\\\\\\\slash'
+```
## Example
```yaml
@@ -35,44 +65,32 @@ from_environment: false
java_opts: -Xloggc:$PWD/beacon_gc.log -verbose:gc
```
-## Memory Settings
-
-The following `JAVA_OPTS` are restricted and will cause the application to fail deployment.
-
-* `-Xms`
-* `-Xmx`
-* `-Xss`
-* `-XX:MaxMetaspaceSize`
-* `-XX:MaxPermSize`
-* `-XX:MetaspaceSize`
-* `-XX:PermSize`
-
-### Allowed Memory Settings
-
-Setting any of the allowed memory settings may require a change to the [Memory Weightings]. Where a value is shown it is the default value for that setting.
+## Allowed Memory Settings
| Argument| Description
| ------- | -----------
-| `-Xmn ` | Maximum size of young generation, known as the eden region. **This could effect the total heap size [Memory Weightings].**
+| `-Xms` | Minimum or initial size of heap.
+| `-Xss` | Size of each thread's stack. **This could effect the total heap size. [JRE Memory]**
+| `-XX:MaxMetaspaceSize` | The maximum size Metaspace can grow to. **This could effect the total heap size. [JRE Memory]**
+| `-XX:MaxPermSize` | The maximum size Permgen can grow to. Only applies to Java 7. **This could effect the total heap size. [JRE Memory]**
+| `-Xmn ` | Maximum size of young generation, known as the eden region.
| `-XX:+UseGCOverheadLimit` | Use a policy that limits the proportion of the VM's time that is spent in GC before an `java.lang.OutOfMemoryError` error is thrown.
| `-XX:+UseLargePages` | Use large page memory. For details, see [Java Support for Large Memory Pages].
| `-XX:-HeapDumpOnOutOfMemoryError` | Dump heap to file when `java.lang.OutOfMemoryError` is thrown.
| `-XX:HeapDumpPath=` | Path to directory or filename for heap dump.
| `-XX:LargePageSizeInBytes=` | Sets the large page size used for the Java heap.
-| `-XX:MaxDirectMemorySize=` | Upper limit on the maximum amount of allocatable direct buffer memory. **This could effect the [Memory Weightings].**
+| `-XX:MaxDirectMemorySize=` | Upper limit on the maximum amount of allocatable direct buffer memory. **This could effect the total heap size. [JRE Memory]**
| `-XX:MaxHeapFreeRatio=` | Maximum percentage of heap free after GC to avoid shrinking.
-| `-XX:MaxNewSize=` | Maximum size of new generation. Since `1.4`, `MaxNewSize` is computed as a function of `NewRatio`. **This could effect the total heap size [Memory Weightings].**
+| `-XX:MaxNewSize=` | Maximum size of new generation. Since `1.4`, `MaxNewSize` is computed as a function of `NewRatio`.
| `-XX:MinHeapFreeRatio=` | Minimum percentage of heap free after GC to avoid expansion.
| `-XX:NewRatio=` | Ratio of old/new generation sizes. 2 is equal to approximately 66%.
-| `-XX:NewSize=` | Default size of new generation. **This could effect the total heap size [Memory Weightings].**
+| `-XX:NewSize=` | Default size of new generation.
| `-XX:OnError=";"` | Run user-defined commands on fatal error.
-| `-XX:OnOutOfMemoryError=";"` | Run user-defined commands when an `java.lang.OutOfMemoryError` is first thrown.
-| `-XX:ReservedCodeCacheSize=` | _Java 8 Only_ Maximum code cache size. Also know as `-Xmaxjitcodesize`. **This could effect the [Memory Weightings].**
+| `-XX:ReservedCodeCacheSize=` | _Java 8 Only_ Maximum code cache size. Also know as `-Xmaxjitcodesize`. **This could effect the total heap size. [JRE Memory]**
| `-XX:SurvivorRatio=` | Ratio of eden/survivor space. Solaris only.
| `-XX:TargetSurvivorRatio=` | Desired ratio of survivor space used after scavenge.
-| `-XX:ThreadStackSize=` | Thread stack size. (0 means use default stack size).
[`config/java_opts.yml`]: ../config/java_opts.yml
[Configuration and Extension]: ../README.md#configuration-and-extension
[Java Support for Large Memory Pages]: http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html
-[Memory Weightings]: jre-open_jdk_jre.md#memory-weightings
+[JRE Memory]: jre-open_jdk_jre.md#memory
diff --git a/docs/framework-jmx-jconsole.png b/docs/framework-jmx-jconsole.png
new file mode 100644
index 0000000000..ed0a52ebb1
Binary files /dev/null and b/docs/framework-jmx-jconsole.png differ
diff --git a/docs/framework-jmx.md b/docs/framework-jmx.md
new file mode 100644
index 0000000000..8d122ccca8
--- /dev/null
+++ b/docs/framework-jmx.md
@@ -0,0 +1,40 @@
+# JMX Framework
+The JMX Framework contributes Java JMX configuration to the application at runtime. **Note:** This framework is only useful in Diego-based containers with SSH access enabled.
+
+
+
+ | Detection Criterion |
+ enabled set in the config/jmx.yml file |
+
+
+ | Tags |
+ jmx=<port> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by creating or modifying the [`config/jmx.yml`][] file in the buildpack fork.
+
+| Name | Description
+| ---- | -----------
+| `enabled` | Whether to enable JMX
+| `port` | The port that the debug agent will listen on. Defaults to `5000`.
+
+## Creating SSH Tunnel
+After starting an application with JMX enabled, an SSH tunnel must be created to the container. To create that SSH container, execute the following command:
+
+```bash
+$ cf ssh -N -T -L :localhost:
+```
+
+The `REMOTE_PORT` should match the `port` configuration for the application (`5000` by default). The `LOCAL_PORT` must match the `REMOTE_PORT`.
+
+Once the SSH tunnel has been created, your JConsole should connect to `localhost:` for JMX access.
+
+
+
+[`config/jmx.yml`]: ../config/jmx.yml
+[Configuration and Extension]: ../README.md#configuration-and-extension
diff --git a/docs/framework-jprofiler_profiler.md b/docs/framework-jprofiler_profiler.md
new file mode 100644
index 0000000000..42902ac42f
--- /dev/null
+++ b/docs/framework-jprofiler_profiler.md
@@ -0,0 +1,46 @@
+# JProfiler Profiler Framework
+The JProfiler Profiler Framework contributes JProfiler configuration to the application at runtime.
+
+
+
+ | Detection Criterion |
+ enabled set in the config/jprofiler_profiler.yml file |
+
+
+ | Tags |
+ jprofiler-profiler=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by creating or modifying the [`config/jprofiler_profiler.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+
+| Name | Description
+| ---- | -----------
+| `enabled` | Whether to enable the JProfiler Profiler
+| `port` | The port that the JProfiler Profiler will listen on. Defaults to `8849`.
+| `nowait` | Whether to start process without waiting for JProfiler to connect first. Defaults to `true`.
+| `repository_root` | The URL of the JProfiler Profiler repository index ([details][repositories]).
+| `version` | The version of the JProfiler Profiler to use. Candidate versions can be found in [this listing][].
+
+## Creating SSH Tunnel
+After starting an application with the JPorfiler Profiler enabled, an SSH tunnel must be created to the container. To create that SSH container, execute the following command:
+
+```bash
+$ cf ssh -N -T -L :localhost:
+```
+
+The `REMOTE_PORT` should match the `port` configuration for the application (`8849` by default). The `LOCAL_PORT` can be any open port on your computer, but typically matches the `REMOTE_PORT` where possible.
+
+Once the SSH tunnel has been created, your JProfiler Profiler should connect to `localhost:` for debugging.
+
+
+
+[`config/jprofiler_profiler.yml`]: ../config/jprofiler_profiler.yml
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[this listing]: http://download.pivotal.io.s3.amazonaws.com/jprofiler/index.yml
+[repositories]: extending-repositories.md
+[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-jprofiler_profiler.png b/docs/framework-jprofiler_profiler.png
new file mode 100644
index 0000000000..e7d34c898b
Binary files /dev/null and b/docs/framework-jprofiler_profiler.png differ
diff --git a/docs/framework-jrebel_agent.md b/docs/framework-jrebel_agent.md
new file mode 100644
index 0000000000..a8923c3058
--- /dev/null
+++ b/docs/framework-jrebel_agent.md
@@ -0,0 +1,37 @@
+# JRebel Agent Framework
+
+The JRebel Agent Framework causes an application to be automatically configured to work with [JRebel][]. Pushing any [JRebel Cloud/Remote][] enabled application (containing `rebel-remote.xml`) will automatically download the latest version of [JRebel][] and set it up for use.
+
+
+
+ | Detection Criterion |
+ Existence of a rebel-remote.xml file inside the application archive. This file is present in every application that is configured to use JRebel Cloud/Remote. |
+
+
+ | Tags |
+ jrebel-agent=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+For more information regarding setup and configuration, please refer to the [JRebel with Pivotal Cloud Foundry tutorial][pivotal].
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by modifying the [`config/jrebel_agent.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+
+| Name | Description
+| ---- | -----------
+| `repository_root` | The URL of the JRebel repository index ([details][repositories]).
+| `version` | The version of JRebel to use. Candidate versions can be found in [this listing][].
+| `enabled` | Whether to activate JRebel (upon the presence of `rebel-remote.xml`) or not.
+
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[`config/jrebel_agent.yml`]: ../config/jrebel_agent.yml
+[JRebel Cloud/Remote]: http://manuals.zeroturnaround.com/jrebel/remoteserver/index.html
+[JRebel]: http://zeroturnaround.com/software/jrebel/
+[pivotal]: http://manuals.zeroturnaround.com/jrebel/remoteserver/pivotal.html
+[repositories]: extending-repositories.md
+[this listing]: http://dl.zeroturnaround.com/jrebel/index.yml
+[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-luna_security_provider.md b/docs/framework-luna_security_provider.md
new file mode 100644
index 0000000000..7fd8ad0cda
--- /dev/null
+++ b/docs/framework-luna_security_provider.md
@@ -0,0 +1,127 @@
+# Luna Security Provider Framework
+The Luna Security Provider Framework causes an application to be automatically configured to work with a bound [Luna Security Service][].
+
+
+
+ | Detection Criterion |
+ Existence of a single bound Luna Security Provider service. The existence of an Luna Security service defined by the VCAP_SERVICES payload containing a service name, label or tag with luna as a substring.
+ |
+
+
+ | Tags |
+ luna-security-provider=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## User-Provided Service
+When binding to the Luna Security Provider using a user-provided service, it must have name or tag with `luna` in it. The credential payload can contain the following entries:
+
+| Name | Description
+| ---- | -----------
+| `client` | A hash containing client configuration
+| `servers` | An array of hashes containing server configuration
+| `groups` | An array of hashes containing group configuration
+
+#### Client Configuration
+| Name | Description
+| ---- | -----------
+| `certificate` | A PEM encoded client certificate
+| `private-key` | A PEM encoded client private key
+
+#### Server Configuration
+| Name | Description
+| ---- | -----------
+| `certificate` | A PEM encoded server certificate
+| `name` | A host name or address
+
+#### Group Configuration
+| Name | Description
+| ---- | -----------
+| `label` | The label for the group
+| `members` | An array of group member serial numbers
+
+### Example Credentials Payload
+```
+{
+ "client": {
+ "certificate": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
+ "private-key": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----"
+ },
+ "servers": [
+ {
+ "name": "test-host-1",
+ "certificate": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----"
+ },
+ {
+ "name": "test-host-2",
+ "certificate": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----"
+ }
+ ],
+ "groups": [
+ {
+ "label": "test-group-1",
+ "members": [
+ "test-serial-number-1",
+ "test-serial-number-2"
+ ]
+ },
+ {
+ "label": "test-group-2",
+ "members": [
+ "test-serial-number-3",
+ "test-serial-number-4"
+ ]
+ }
+ ]
+}
+```
+
+### Creating Credential Payload
+In order to create the credentials payload, you should collapse the JSON payload to a single line and set it like the following
+
+```
+$ cf create-user-provided-service luna -p '{"client":{"certificate":"-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----","private-key":"-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----"},"servers":[{"name":"test-host-1","certificate":"-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----"},{"name":"test-host-2","certificate":"-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----"}],"groups":[{"label":"test-group-1","members":["test-serial-number-1","test-serial-number-2"]},{"label":"test-group-2","members":["test-serial-number-3","test-serial-number-4"]}]}'
+```
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by modifying the [`config/luna_security_provider.yml`][] file in the buildpack. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+
+| Name | Description
+| ---- | -----------
+| `ha_logging_enabled` | Whether to enable HA logging for the Luna Security Provider. Defaults to `true`.
+| `logging_enabled` | Whether to enable the logging wrapper for the Luna Security Provider. Defaults to `false`.
+| `tcp_keep_alive_enabled` | Whether to enable the client TCP keep alive setting for the Luna Security Provider. Defaults to `false`.
+| `repository_root` | The URL of the Luna Security Provider repository index ([details][repositories]).
+| `version` | Version of the Luna Security Provider to use.
+
+### Additional Resources
+The framework can also be configured by overlaying a set of resources on the default distribution. To do this follow one of the options below.
+
+Configuration files are created in this order:
+
+1. Default configuration
+2. Buildpack fork
+3. Buildpack generated configuration if the bound service has both a `servers` and `groups` key
+4. External configuration if configured
+
+#### Buildpack Fork
+Add files to the `resources/luna_security_provider` directory in the buildpack fork. For example, to override the default `Chrystoki.conf` add your custom file to `resources/luna_security_provider/Chrystoki.conf`.
+
+#### External Configuration
+Set `LUNA_CONF_HTTP_URL` to an HTTP or HTTPS URL which points to the directory where your configuration files exist. You may also include a user and password in the URL, like `https://user:pass@example.com`.
+
+The Java buildpack will take the URL to the directory provided and attempt to download the following files from that directory:
+
+- `Chrystoki.conf`
+- `server-certificates.pem`
+
+Any file successfully downloaded will be copied to the configuration directory. The buildpack does not fail if files are missing.
+
+[`config/luna_security_provider.yml`]: ../config/luna_security_provider.yml
+[Luna Security Service]: http://www.safenet-inc.com/data-encryption/hardware-security-modules-hsms/
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[repositories]: extending-repositories.md
+[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-maria_db_jdbc.md b/docs/framework-maria_db_jdbc.md
index cd90ced0f9..635767f92f 100644
--- a/docs/framework-maria_db_jdbc.md
+++ b/docs/framework-maria_db_jdbc.md
@@ -4,18 +4,18 @@ The MariaDB JDBC Framework causes a JDBC driver JAR to be automatically download
| Detection Criterion |
- Existence of a single bound MariaDB or MySQL service and no provided MariaDB or MySQL JDBC JAR.
+ | Existence of a single bound MariaDB or MySQL service and NO provided MariaDB or MySQL JDBC jar.
- - Existence of a MariaDB service is defined as the
VCAP_SERVICES payload containing a service who's name, label or tag has mariadb as a substring.
- - Existence of a MySQL service is defined as the
VCAP_SERVICES payload containing a service who's name, label or tag has mysql as a substring.
- - Existence of a MariaDB JDBC JAR is defined as the application containing a JAR who's name matches mariadb-java-client*.jar
- - Existence of a MySQL JDBC JAR is defined as the application containing a JAR who's name matches mysql-connector-java*.jar
+ - Existence of a MariaDB service is defined as the
VCAP_SERVICES payload containing a service whose name, label or tag has mariadb as a substring.
+ - Existence of a MySQL service is defined as the
VCAP_SERVICES payload containing a service whose name, label or tag has mysql as a substring.
+ - Existence of a MariaDB JDBC jar is defined as the application containing a JAR whose name matches
mariadb-java-client*.jar
+ - Existence of a MySQL JDBC jar is defined as the application containing a JAR whose name matches
mysql-connector-j*.jar
|
| Tags |
- maria-db-jdbc=<version> |
+ maria-db-jdbc=<version> |
Tags are printed to standard output by the buildpack detect script
@@ -24,7 +24,7 @@ Tags are printed to standard output by the buildpack detect script
Users may optionally provide their own MariaDB or MySQL service. A user-provided MariaDB or MySQL service must have a name or tag with `mariadb` or `mysql` in it so that the MariaDB JDBC Framework will automatically download the JDBC driver JAR and place it on the classpath.
## Configuration
-For general information on configuring the buildpack, refer to [Configuration and Extension][].
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
The framework can be configured by modifying the [`config/maria_db_jdbc.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
diff --git a/docs/framework-metric_writer.md b/docs/framework-metric_writer.md
new file mode 100644
index 0000000000..aeaaff0a5a
--- /dev/null
+++ b/docs/framework-metric_writer.md
@@ -0,0 +1,44 @@
+# Metric Writer Framework
+The Metric Writer Framework causes an application to be automatically configured to add Cloud Foundry-specific Micrometer tags.
+
+
+
+ | Detection Criterion |
+ Existence of a micrometer-core*.jar file in the application directory |
+
+
+ | Tags |
+ metric-writer-reconfiguration=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+The Metric Writer Framework adds a set of CloudFoundry-specific Micrometer tags to any Micrometer metric that does not already contain the keys. The values of these tags can be explicitly configured via environment variables otherwise they default to values extracted from the standard Cloud Foundry runtime environment.
+
+| Tag | Environment Variable | Default
+| --- | ---------------------| -----------
+| `cf.account` | `CF_APP_ACCOUNT` | `$VCAP_APPLICATION / cf_api`
+| `cf.application` | `CF_APP_APPLICATION`| `$VCAP_APPLICATION / application_name / frigga:name`
+| `cf.cluster` | `CF_APP_CLUSTER` | `$VCAP_APPLICATION / application_name / frigga:cluster`
+| `cf.version` | `CF_APP_VERSION` | `$VCAP_APPLICATION / application_name / frigga:revision`
+| `cf.instance.index` | `CF_APP_INSTANCE_INDEX` | `$CF_INSTANCE_INDEX`
+| `cf.organization` | `CF_APP_ORGANIZATION` | `$VCAP_APPLICATION / organization_name`
+| `cf.space` | `CF_APP_SPACE` | `$VCAP_APPLICATION / space_name`
+
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by modifying the [`config/metric_writer.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+
+| Name | Description
+| ---- | -----------
+| `enabled` | Whether to attempt metric augmentation
+| `repository_root` | The URL of the Metric Writer repository index ([details][repositories]).
+| `version` | The version of Metric Writer to use. Candidate versions can be found in [this listing][].
+
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[`config/metric_writer.yml`]: ../config/metric_writer.yml
+[repositories]: extending-repositories.md
+[this listing]: https://java-buildpack.cloudfoundry.org/metric-writer/index.yml
+[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-multi_buildpack.md b/docs/framework-multi_buildpack.md
new file mode 100644
index 0000000000..29f165c9d0
--- /dev/null
+++ b/docs/framework-multi_buildpack.md
@@ -0,0 +1,40 @@
+# Multiple Buildpack Framework
+The Multiple Buildpack Framework enables the Java Buildpack to act as the final buildpack in a multiple buildpack deployment. It reads the contributions of other, earlier buildpacks and incorporates them into its standard staging.
+
+The Java Options Framework contributes arbitrary Java options to the application at runtime.
+
+
+
+ | Detection Criterion |
+ Existence of buildpack contribution directories (typically /tmp/<RANDOM>/deps/<INDEX> containing a config.yml file. |
+
+
+ | Tags |
+ multi-buildpack=<BUILDPACK_NAME>,... |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## Multiple Buildpack Integration API
+When the Java Buildpack acts as the final buildpack in a multiple buildpack deployment it honors the following core contract integration points.
+
+| Integration Point | Buildpack Usage
+| ----------------- | ---------------
+| `/bin` | An existing `/bin` directory contributed by a non-final buildpack will be added to the `$PATH` of the application as it executes
+| `/lib` | An existing `/lib` directory contributed by a non-final buildpack will be added to the `$LD_LIBRARY_PATH` of the application as it executes
+
+In addition to the core contract, the Java Buildpack defines the following keys in `config.yml` as extension points for contributing to the application. **All keys are optional, and all paths are absolute.**
+
+| Key | Type | Description
+| --- | ---- | -----------
+| `additional_libraries` | `[ path ]` | An array of absolute paths to libraries will be added to the application's classpath
+| `environment_variables` | `{ string, ( path \| string ) }` | A hash of string keys to absolute path or string values that will be added as environment variables
+| `extension_directories` | `[ path ]` | An array of absolute paths to directories containing JRE extensions
+| `java_opts.agentpaths` | `[ path ]` | An array of absolute paths to libraries that will be added as agents
+| `java_opts.agentpaths_with_props` | `{ path, { string, string } }` | A nested hash with absolute paths keys and hashes of string keys and string values as a value that will be added as agents with properties
+| `java_opts.bootclasspath_ps` | `[ path ]` | An array of absolute paths that will be added to the application's bootclasspath
+| `java_opts.javaagents` | `[ path ]` | An array of absolute paths that will be added as javaagents
+| `java_opts.preformatted_options` | `[ string ]` | An array of strings that will be added as options without modification
+| `java_opts.options` | `{ string, ( path \| string ) }` | A hash of string keys to absolute path or string values that will be added as options
+| `java_opts.system_properties` | `{ string , ( path \| string ) }` | A hash of string keys to absolute path or string values that will be added as system properties
+| `security_providers` | `[ string ]` | An array of strings to be added to list of security providers
diff --git a/docs/framework-new_relic_agent.md b/docs/framework-new_relic_agent.md
index 815781cd70..b30336d3fd 100644
--- a/docs/framework-new_relic_agent.md
+++ b/docs/framework-new_relic_agent.md
@@ -23,10 +23,12 @@ The credential payload of the service may contain the following entries:
| Name | Description
| ---- | -----------
-| `licenseKey` | The license key to use when authenticating
+| `license_key` | (Optional) Either this credential or `licenseKey` must be provided. If both are provided then the value for `license_key` will always win. The license key to use when authenticating.
+| `licenseKey` | (Optional) As above.
+| `***` | (Optional) Any additional entries will be applied as a system property appended to `-Dnewrelic.config.` to allow full configuration of the agent.
## Configuration
-For general information on configuring the buildpack, refer to [Configuration and Extension][].
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
The framework can be configured by modifying the [`config/new_relic_agent.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
@@ -34,6 +36,28 @@ The framework can be configured by modifying the [`config/new_relic_agent.yml`][
| ---- | -----------
| `repository_root` | The URL of the New Relic repository index ([details][repositories]).
| `version` | The version of New Relic to use. Candidate versions can be found in [this listing][].
+| `extensions.repository_root` | The URL of the Extensions repository index ([details][repositories]).
+| `extensions.version` | The version of the Extensions to use. Candidate versions can be found in the the repository that you have created to house the Extensions.
+
+### Extensions
+
+Custom New Relic instrumentation in the form of [Extension XML Files][] (or JARs) may be provided via a custom repository.
+
+Example in a manifest.yml
+
+```yaml
+env:
+ JBP_CONFIG_NEW_RELIC_AGENT: '{ extensions: { repository_root: "http://repository..." } }'
+```
+
+The artifacts that the repository provides must be in TAR format and must include the extension files in a directory, with a structure like:
+
+```
+extensions
+|- my-extension.xml
+|- my-other-extension.jar
+|...
+```
### Additional Resources
The framework can also be configured by overlaying a set of resources on the default distribution. To do this, add files to the `resources/new_relic_agent` directory in the buildpack fork. For example, to override the default `new_relic.yml` add your custom file to `resources/new_relic_agent/newrelic.yml`.
@@ -42,5 +66,6 @@ The framework can also be configured by overlaying a set of resources on the def
[`config/new_relic_agent.yml`]: ../config/new_relic_agent.yml
[New Relic Service]: https://newrelic.com
[repositories]: extending-repositories.md
-[this listing]: http://download.pivotal.io.s3.amazonaws.com/new-relic/index.yml
+[this listing]: https://download.run.pivotal.io/new-relic/index.yml
[version syntax]: extending-repositories.md#version-syntax-and-ordering
+[Extension XML Files]: https://docs.newrelic.com/docs/agents/java-agent/custom-instrumentation/java-instrumentation-xml
diff --git a/docs/framework-open_telemetry_javaagent.md b/docs/framework-open_telemetry_javaagent.md
new file mode 100644
index 0000000000..26706700cd
--- /dev/null
+++ b/docs/framework-open_telemetry_javaagent.md
@@ -0,0 +1,50 @@
+# OpenTelemetry Javaagent
+
+The OpenTelemetry Javaagent buildpack framework will cause an application to be automatically instrumented
+with the [OpenTelemetry Javaagent Instrumentation](https://github.com/open-telemetry/opentelemetry-java-instrumentation).
+
+Data will be sent directly to the OpenTelemetry Collector.
+
+
+
+ | Detection Criterion |
+ Existence of a bound service containing the string otel-collector |
+
+
+ | Tags |
+ opentelemetry-javaagent=<version> |
+
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## User-Provided Service
+
+Users are currently expected to `create-user-provided-service` (cups) of the collector
+and bind it to their application. The service MUST contain the string `otel-collector`.
+
+For example, to create a service named `otel-collector` that represents an environment named `cf-demo`, you could use the following commands:
+
+```
+$ cf cups otel-collector -p '{"otel.exporter.otlp.endpoint" : "https://my-collector-endpoint", "otel.exporter.otlp.headers" : "authorization=Basic SOMEBAS64STRING","otel.exporter.otlp.protocol" : "grpc", "otel.traces.exporter" : "otlp", "otel.metrics.exporter" : "otlp", "otel.resource.attributes": "deployment.environment=cf-demo"}'
+$ cf bind-service myApp otel-collector
+$ cf restage myApp
+```
+
+Additional configuration options for the Agent can be found [here](https://opentelemetry.io/docs/instrumentation/java/automatic/agent-config/#configuring-with-environment-variables)
+
+### Choosing a version
+
+Most users should skip this and simply use the latest version of the agent available (the default).
+To override the default and choose a specific version, you can use the `JBP_CONFIG_*` mechanism
+and set the `JBP_CONFIG_OPENTELEMETRY_JAVAAGENT` environment variable for your application.
+
+For example, to use version 1.27.0 of the OpenTelemetry Javaagent Instrumentation, you
+could run:
+```
+$ cf set-env testapp JBP_CONFIG_OPENTELEMETRY_JAVAAGENT '{version: 1.27.0}'
+```
+
+# Additional Resources
+
+* [OpenTelemetry Javaagent Instrumentation](https://github.com/open-telemetry/opentelemetry-java-instrumentation) on GitHub
diff --git a/docs/framework-play_framework_auto_reconfiguration.md b/docs/framework-play_framework_auto_reconfiguration.md
deleted file mode 100644
index a56a5d2b55..0000000000
--- a/docs/framework-play_framework_auto_reconfiguration.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# Play Framework Auto-reconfiguration Framework
-The Play Framework Auto-reconfiguration Framework causes an application to be automatically reconfigured to work with configured cloud services.
-
-
-
- | Detection Criterion |
- An application is a Play Framework application |
-
-
- | Tags |
- play-framework-auto-reconfiguration=<version> |
-
-
-Tags are printed to standard output by the buildpack detect script
-
-## Configuration
-For general information on configuring the buildpack, refer to [Configuration and Extension][].
-
-The framework can be configured by modifying the [`config/play_framework_auto_reconfiguration.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
-
-
-| Name | Description
-| ---- | -----------
-| `enabled` | Whether to attempt auto-reconfiguration
-| `repository_root` | The URL of the Auto-reconfiguration repository index ([details][repositories]).
-| `version` | The version of Auto-reconfiguration to use. Candidate versions can be found in [this listing][].
-
-[Configuration and Extension]: ../README.md#configuration-and-extension
-[`config/play_framework_auto_reconfiguration.yml`]: ../config/config/play_framework_auto_reconfiguration.yml
-[repositories]: extending-repositories.md
-[this listing]: http://download.pivotal.io.s3.amazonaws.com/auto-reconfiguration/index.yml
-[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-play_framework_jpa_plugin.md b/docs/framework-play_framework_jpa_plugin.md
deleted file mode 100644
index f5ab7331fa..0000000000
--- a/docs/framework-play_framework_jpa_plugin.md
+++ /dev/null
@@ -1,36 +0,0 @@
-# Play Framework JPA Plugin Framework
-The Play Framework JPA Plugin Framework causes an application to be automatically reconfigured to work with configured cloud services.
-
-
-
- | Detection Criterion |
-
-
- - An application is a Play Framework 2.0 application
- - An application uses the play-java-jpa plugin
-
- |
-
-
- | Tags |
- play-framework-jpa-plugin=<version> |
-
-
-Tags are printed to standard output by the buildpack detect script
-
-## Configuration
-For general information on configuring the buildpack, refer to [Configuration and Extension][].
-
-The framework can be configured by modifying the [`config/play_framework_jpa_plugin.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
-
-| Name | Description
-| ---- | -----------
-| `enabled` | Whether to attempt reconfiguration
-| `repository_root` | The URL of the Play Framework JPA Plugin repository index ([details][repositories]).
-| `version` | The version of the Play Framework JPA Plugin to use. Candidate versions can be found in [this listing][].
-
-[Configuration and Extension]: ../README.md#configuration-and-extension
-[`config/play_framework_jpa_plugin.yml`]: ../config/play_framework_jpa_plugin.yml
-[repositories]: extending-repositories.md
-[this listing]: http://download.pivotal.io.s3.amazonaws.com/play-jpa-plugin/index.yml
-[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-postgresql_jdbc.md b/docs/framework-postgresql_jdbc.md
index 17352ecabf..bff4a17844 100644
--- a/docs/framework-postgresql_jdbc.md
+++ b/docs/framework-postgresql_jdbc.md
@@ -22,7 +22,7 @@ Tags are printed to standard output by the buildpack detect script
Users may optionally provide their own PostgreSQL service. A user-provided PostgreSQL service must have a name or tag with `postgres` in it so that the PostgreSQL JDBC Framework will automatically download the JDBC driver JAR and place it on the classpath.
## Configuration
-For general information on configuring the buildpack, refer to [Configuration and Extension][].
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
The framework can be configured by modifying the [`config/postgresql_jdbc.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
diff --git a/docs/framework-protect_app_security_provider.md b/docs/framework-protect_app_security_provider.md
new file mode 100644
index 0000000000..b1dd5d6d4e
--- /dev/null
+++ b/docs/framework-protect_app_security_provider.md
@@ -0,0 +1,96 @@
+# ProtectApp Security Provider Framework
+The ProtectApp Security Provider Framework causes an application to be automatically configured to work with a bound [ProtectApp Security Service][].
+
+
+
+ | Detection Criterion |
+ Existence of a single bound ProtectApp Security Provider service. The existence of an ProtectApp Security service defined by the VCAP_SERVICES payload containing a service name, label or tag with protectapp as a substring.
+ |
+
+
+ | Tags |
+ protect-app-security-provider=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## User-Provided Service
+When binding to the ProtectApp Security Provider using a user-provided service, it must have name or tag with `protectapp` in it. The credential payload can contain the following entries:
+
+| Name | Description
+| ---- | -----------
+| `client` | The client configuration
+| `trusted_certificates` | An array of certs containing trust information
+| `NAE_IP.1` | A list of KeySecure server ips or hostnames to be used
+| `***` | (Optional) Any additional entries will be applied as a system property appended to `-Dcom.ingrian.security.nae.` to allow full configuration of the library.
+
+#### Client Configuration
+| Name | Description
+| ---- | -----------
+| `certificate` | A PEM encoded client certificate
+| `private_key` | A PEM encoded client private key
+
+#### Trusted Certs Configuration
+One or more PEM encoded certificate
+
+### Example Credentials Payload
+```
+{
+ "client": {
+ "certificate": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
+ "private_key": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----"
+ },
+ "trusted_certificates": [
+ "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
+ "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----"
+ ],
+ "NAE_IP.1": "192.168.1.25:192.168.1.26"
+}
+```
+
+### Creating Credential Payload
+In order to create the credentials payload, you should collapse the JSON payload to a single line and set it like the following
+
+```
+$ cf create-user-provided-service protectapp -p '{"client":{"certificate":"-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----","private_key":"-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----"},"trusted_certificates":["-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----","-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----"],"NAE_IP.1":"192.168.1.25:192.168.1.26"}'
+```
+
+You may want to use a file for this
+
+Note the client portion is very exacting and needs line breaks in the body every 64 characters.
+
+1. The file must contain:
+`-----BEGIN CERTIFICATE-----`
+on a separate line (i.e. it must be terminated with a newline).
+1. Each line of "gibberish" must be 64 characters wide.
+1. The file must end with:
+`-----END CERTIFICATE-----`
+and also be terminated with a newline.
+1. Don't save the cert text with Word. It must be in ASCII.
+1. Don't mix DOS and UNIX style line terminations.
+
+So, here are a few steps you can take to normalize your certificate:
+
+1. Run it through `dos2unix`
+`$ dos2unix cert.pem`
+1. Run it through `fold`
+`$ fold -w 64 cert.pem`
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by modifying the [`config/protect_app_security_provider.yml`][] file in the buildpack. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+
+| Name | Description
+| ---- | -----------
+| `repository_root` | The URL of the ProtectApp Security Provider repository index ([details][repositories]).
+| `version` | Version of the ProtectApp Security Provider to use.
+
+### Additional Resources
+The framework can also be configured by overlaying a set of resources on the default distribution. To do this, add files to the `resources/protect_app_security_provider` directory in the buildpack fork.
+
+[`config/protect_app_security_provider.yml`]: ../config/protect_app_security_provider.yml
+[ProtectApp Security Service]: https://safenet.gemalto.com/data-encryption/protectapp-application-protection/
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[repositories]: extending-repositories.md
+[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-riverbed_appinternals_agent.md b/docs/framework-riverbed_appinternals_agent.md
new file mode 100644
index 0000000000..f0012a01f6
--- /dev/null
+++ b/docs/framework-riverbed_appinternals_agent.md
@@ -0,0 +1,58 @@
+# Riverbed Appinternals Agent Framework
+The Riverbed Appinternals Agent Framework causes an application to be bound with a Riverbed Appinternals service instance.
+
+
+
+ | Detection Criterion | Existence of a single bound Riverbed Appinternals agent service. The existence of an agent service is defined by the VCAP_SERVICES payload containing a service name, label or tag with appinternals as a substring.
+ |
+
+
+ | Tags |
+ riverbed-appinternals-agent=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## User-Provided Service
+When binding Appinternals using a user-provided service, it must have appinternals as substring. The credential payload can contain the following entries:
+
+| Name | Description
+| ---- | -----------
+| `rvbd_dsa_port` | (Optional)The AppInternals agent (DSA) port (default 2111).
+| `rvbd_agent_port` | (Optional) The AppInternals agent socket port (default 7073).
+| `rvbd_moniker` | (Optional) A custom name for the application (default supplied by agent process discovery).
+
+**NOTE**
+
+Change `rvbd_dsa_port` and `rvbd_agent_port` only if there is a port conflict
+
+### Example: Creating Riverbed Appinternals User-Provided Service Payload
+
+```
+cf cups spring-music-appinternals -p '{"rvbd_dsa_port":"9999","rvbd_moniker":"my_app"}'
+cf bind-service spring-music spring-music-appinternals
+```
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by modifying the [`config/riverbed_appinternals_agent.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+
+| Name | Description
+| ---- | -----------
+| `repository_root` | The URL of the Riverbed Appinternals agent repository index ([details][repositories]).
+| `version` | The version of the Riverbed Appinternals agent to use.
+
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[repositories]: extending-repositories.md
+[version syntax]: extending-repositories.md#version-syntax-and-ordering
+[`config/riverbed_appinternals_agent.yml`]: ../config/riverbed_appinternals_agent.yml
+
+
+**NOTE**
+
+If the Riverbed Service Broker's version is greater than or equal to 10.20, the buildpack will instead download Riverbed AppInternals agent from Riverbed Service Broker and will fall back to using `repository_root` in [`config/riverbed_appinternals_agent.yml`][] only if Service Broker failed to serve the Agent artifact.
+
+**NOTE**
+
+If the Rivered verstion is 10.21.9 or later, the buildpack will load the profiler normally, instead of from the Service Broker. This allows for creating multiple offline buildpacks containing different versions.
diff --git a/docs/framework-sealights_agent.md b/docs/framework-sealights_agent.md
new file mode 100644
index 0000000000..235254b8a9
--- /dev/null
+++ b/docs/framework-sealights_agent.md
@@ -0,0 +1,54 @@
+# Sealights Agent Framework
+The Sealights Agent Framework causes an application to be automatically configured to work with [Sealights Service][].
+
+
+
+ | Detection Criterion | Existence of a single bound sealights service. The existence of a sealights service defined by the VCAP_SERVICES payload containing a service name, label or tag with sealights as a substring.
+ |
+
+
+ | Tags | sealights-agent=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## User-Provided Service
+When binding Sealights using a user-provided service, it must have name or tag with `sealights` in it.
+The credential payload can contain the following entries.
+
+| Name | Description
+| ---- | -----------
+| `token` | A Sealights Agent token
+| `proxy` | Specify a HTTP proxy used to communicate with the Sealights backend. Required when a corporate network prohibits communication to cloud services. The default is to have no proxy configured. This does not inherit from `http_proxy`/`https_proxy` or `http.proxyHost/https.proxyHost`, you must set this specifically if a proxy is needed.
+| `lab_id` | Specify a Sealights [Lab ID][]
+
+All fields above except the agent token may be also specified in the [Configuration Section](#configuration) below.
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by modifying the [`config/sealights_agent.yml`][] file. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+
+| Name | Description
+| ---- | -----------
+| `build_session_id` | Sealights [Build Session ID][] for the application. Leave blank to use the value embedded in the jar/war artifacts
+| `proxy` | Specify a HTTP proxy used to communicate with the Sealights backend. Required when a corporate network prohibits communication to cloud services. The default is to have no proxy configured. This does not inherit from `http_proxy`/`https_proxy` or `http.proxyHost/https.proxyHost`, you must set this specifically if a proxy is needed.
+| `lab_id` | Specify a Sealights [Lab ID][]
+| `auto_upgrade` | Enable/disable agent auto-upgrade. Off by default
+| `version` | The version of Auto-reconfiguration to use. Candidate versions can be found in [this listing][]. If auto_upgrade is turned on, a different version may be downloaded and used at runtime
+
+Configuration settings will take precedence over the ones specified in the [User-Provided Service](#user-provided-service), if those are defined.
+
+## Troubleshooting and Support
+
+For additional documentation and support, visit the official [Sealights Java agents documentation] page
+
+[`config/sealights_agent.yml`]: ../config/sealights_agent.yml
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[repositories]: extending-repositories.md
+[version syntax]: extending-repositories.md#version-syntax-and-ordering
+[Sealights Service]: https://www.sealights.io
+[Build Session ID]: https://sealights.atlassian.net/wiki/spaces/SUP/pages/3473472/Using+Java+Agents+-+Generating+a+session+ID
+[Lab ID]: https://sealights.atlassian.net/wiki/spaces/SUP/pages/762413124/Using+Java+Agents+-+Running+Tests+in+Parallel+Lab+Id
+[this listing]: https://agents.sealights.co/pcf/index.yml
+[Sealights Java agents documentation]: https://sealights.atlassian.net/wiki/spaces/SUP/pages/3014685/SeaLights+Java+agents
diff --git a/docs/framework-seeker_security_provider.md b/docs/framework-seeker_security_provider.md
new file mode 100644
index 0000000000..d4af7dd408
--- /dev/null
+++ b/docs/framework-seeker_security_provider.md
@@ -0,0 +1,24 @@
+# Seeker Security Provider Framework
+The Seeker Security Provider Framework causes an application to be bound with a [Seeker Security Provider][s] service instance.
+
+
+
+ | Detection Criterion | Existence of a single bound Seeker Security Provider service. The existence of a provider service is defined by the VCAP_SERVICES payload containing a service name, label or tag with seeker as a substring.
+ |
+
+
+ | Tags |
+ seeker-service-provider |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## User-Provided Service
+When binding Appinternals using a user-provided service, it must have seeker as substring. The credential payload must contain the following entries:
+
+| Name | Description
+| ---- | -----------
+| `seeker_server_url` | The fully qualified URL of a Synopsys Seeker Server (e.g. `https://seeker.example.com`)
+
+**NOTE**
+In order to use this integration, the Seeker Server version must be at least `2019.08` or later.
diff --git a/docs/framework-sky_walking_agent.md b/docs/framework-sky_walking_agent.md
new file mode 100644
index 0000000000..1f32898601
--- /dev/null
+++ b/docs/framework-sky_walking_agent.md
@@ -0,0 +1,48 @@
+# SkyWalking Agent Framework
+The SkyWalking Agent Framework causes an application to be automatically configured to work with a bound [SkyWalking Service][] **Note:** This framework is disabled by default.
+
+
+
+ | Detection Criterion | Existence of a single bound SkyWalking service. The existence of an SkyWalking service defined by the VCAP_SERVICES payload containing a service name, label or tag with sky-walking or skywalking as a substring.
+ |
+
+
+ | Tags | sky-walking-agent=<version> |
+
+
+Tags are printed to standard output by the buildpack detect script
+
+## User-Provided Service
+When binding SkyWalking using a user-provided service, it must have name or tag with `sky-walking` or `skywalking` in it. The credential payload can contain the following entries. **Note:** Credentials marked as "(Optional)" may be required for some versions of the SkyWalking agent. Please see the [SkyWalking Java Agent Configuration Properties][] for the version of the agent used by your application for more details.
+
+| Name | Description
+| ---- | -----------
+| `application-name` | (Optional) The application's name
+| `sample-n-per-3-secs` | (Optional) The number of sampled traces per 3 seconds. Negative number means sample traces as many as possible, most likely 100%
+| `span-limit-per-segment` | (Optional) The max amount of spans in a single segment
+| `ignore-suffix` | (Optional) Ignore the segments if their operation names start with these suffix
+| `open-debugging-class` | (Optional) If true, skywalking agent will save all instrumented classes files in `/debugging` folder.Skywalking team may ask for these files in order to resolve compatible problem
+| `servers` | Server addresses .Examples: Single collector:servers="127.0.0.1:8080",Collector cluster:servers="10.2.45.126:8080,10.2.45.127:7600"
+| `logging-level` | (Optional) Logging level
+
+## Configuration
+For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
+
+The framework can be configured by modifying the [`config/sky_walking_agent.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+
+| Name | Description
+| ---- | -----------
+| `default_application_name` | This is omitted by default but can be added to specify the application name in the SkyWalking dashboard. This can be overridden by an `application-name` entry in the credentials payload. If neither are supplied the default is the `application_name` as specified by Cloud Foundry.
+| `repository_root` | The URL of the SkyWalking repository index ([details][repositories]).
+| `version` | The version of SkyWalking to use. Candidate versions can be found in [this listing][].
+
+### Additional Resources
+The framework can also be configured by overlaying a set of resources on the default distribution. To do this, add files to the `resources/sky_walking_agent` directory in the buildpack fork.
+
+[`config/sky_walking_agent.yml`]: ../config/sky_walking_agent.yml
+[SkyWalking Java Agent Configuration Properties]: https://github.com/apache/incubator-skywalking/blob/master/docs/en/Deploy-skywalking-agent.md
+[SkyWalking Service]: http://skywalking.io
+[Configuration and Extension]: ../README.md#configuration-and-extension
+[repositories]: extending-repositories.md
+[this listing]: https://download.run.pivotal.io/sky-walking/index.yml
+[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-splunk_otel_java_agent.md b/docs/framework-splunk_otel_java_agent.md
new file mode 100644
index 0000000000..f6c0bf2a5f
--- /dev/null
+++ b/docs/framework-splunk_otel_java_agent.md
@@ -0,0 +1,64 @@
+# Splunk Distribution of OpenTelemetry Java Instrumentation
+
+This buildpack framework automatically instruments your Java application
+with the [Splunk distribution of OpenTelemetry Java Instrumentation](https://github.com/signalfx/splunk-otel-java)
+to send trace data to Splunk Observability Cloud.
+
+
+
+ | Detection Criterion |
+ Existence of a bound service containing the string splunk-o11y |
+
+
+ | Tags |
+ splunk-otel-java-agent=<version> |
+
+
+
+The buildpack detect script prints tags to standard output.
+
+## User-Provided Service
+
+
+Provide your own "user provided service" (cups) instance and bind
+it to your application.
+
+The service name MUST contain the string `splunk-o11y`.
+
+For example, to create a service named `splunk-o11y` that represents Observability Cloud
+realm `us0` and represents a user environment named `cf-demo`, use the following
+commands:
+
+```
+$ cf cups splunk-o11y -p \
+ '{"splunk.realm": "us0", "splunk.access.token": "", "otel.resource.attributes": "deployment.environment=cf-demo"}'
+$ cf bind-service myApp splunk-o11y
+$ cf restage myApp
+```
+
+Provide the following values using the `credential` field of the service:
+
+| Name | Required? | Description
+|------------------------|-----------| -----------
+| `splunk.access.token` | Yes | Splunk [org access token](https://docs.splunk.com/observability/admin/authentication-tokens/org-tokens.html).
+| `splunk.realm` | Yes | Splunk realm where data will be sent. This is commonly `us0`, `eu0`, and so on. See [Available regions or realms](https://docs.splunk.com/observability/en/get-started/service-description.html#available-regions-or-realms) for more information.
+| `otel.*` or `splunk.*` | Optional | All additional credentials starting with these prefixes are appended to the application's JVM arguments as system properties.
+
+### Choosing a version
+
+To override the default and choose a specific version, use the `JBP_CONFIG_*` mechanism
+and set the `JBP_CONFIG_SPLUNK_OTEL_JAVA_AGENT` environment variable for your application.
+
+For example, to use version 1.16.0 of the Splunk OpenTelemetry Java Instrumentation, run:
+
+```
+$ cf set-env testapp JBP_CONFIG_SPLUNK_OTEL_JAVA_AGENT '{version: 1.16.0}'
+```
+
+In most cases you can use the latest or default version of the agent available.
+
+# Additional Resources
+
+* [Splunk Observability](https://www.splunk.com/en_us/products/observability.html)
+* [Official documentation of the Splunk Java agent](https://docs.splunk.com/observability/en/gdi/get-data-in/application/java/get-started.html)
+* [Splunk Distribution of OpenTelemetry Java](https://github.com/signalfx/splunk-otel-java) on GitHub
diff --git a/docs/framework-spring_auto_reconfiguration.md b/docs/framework-spring_auto_reconfiguration.md
index 86b0708e65..c13280acde 100644
--- a/docs/framework-spring_auto_reconfiguration.md
+++ b/docs/framework-spring_auto_reconfiguration.md
@@ -13,10 +13,10 @@ The Spring Auto-reconfiguration Framework causes an application to be automatica