This is documentation for Apprenda 7 and 8.
Documentation for newer version is available at https://new.docs.apprenda.com.

Java Hosting

On the Configuration>Java Hosting page of the SOC, you are able to view and manage the default Java runtimes and hosting containers for your Platform. You are also able to add new runtime versions and hosting containers to use your Platform from this page.

Runtime Versions

When Java nodes are added to a Platform, the Platform will install a default set of supported JRE versions. You can view and manage supported JRE versions from the Runtime Versions section of the Configuration>Java Hosting page.

See the supported software page for the default runtime support shipped with the Platform.

The Runtime Versions table on the Java Hosting page shows all available runtimes for your Platform. For each runtime you can see the unique Name, Version, and Path to the runtime version on a node (equivalent to JRE_HOME and must be uniform across all Platform Java Nodes).

Additionally, the table will indicate if the JRE version is Enabled for Developers to assign to application components, the Default runtime for Java Web application components the Platform will use when a Developer hasn't assigned a runtime, and if the runtime was shipped with the Platform as a System runtime. 

Note: Support for TLS 1.2 was added in Platform version 8.1.0. If your Platform is configured to use TLS 1.2, it is recommended that your Java applications use JRE 1.8 due to limitations on TLS 1.2 support in JRE 1.6 and JRE 1.7. 

Add a New Runtime Version

If you need a different JRE runtime version than the ones shipped with the Platform, you are able to add new runtime versions to the Platform. Once added, the JRE can be used for future deployments of an application.

You can enable an added JRE so that Developers can assign it to their applications before deployment. You can also set an added JRE as the default version the Platform should used for all deployments that have no Developer assigned JRE version.

Prerequisites

  • JRE runtime version installed to a uniform path on all Platform Java nodes

If the new runtime version has been installed, click the New Runtime Version button and

  1. fill in a unique Name the runtime. Note that Developers will only see runtime names in the Developer Portal when assigning runtimes for an application. Information in the Version field is not shown to Developers, so its recommended to use descriptive names for runtime names so Developers can choose the correct runtime for their applications.
  2. fill in the Version of the JRE runtime
  3. fill in JRE Home Path where you installed the runtime on all Java nodes
  4. select the Enabled checkbox to make the new runtime available to Developers. If left un-checked, Developers will not be able to choose this runtime for their applications
  5. select the Default checkbox to set the new runtime as the default for all Java workloads that don't have a runtime set by a Developer

Click Save when you are finished imputing the information. The new runtime version will appear on the Runtime Versions table.

Edit or Delete an Existing Runtime Version

To Edit an existing runtime version, click on its corresponding Edit button (or the click on the menu button next to it to display more options):

You can change Default and Enabled settings for all runtime versions. The default runtime is used for all deployments where a Developer has not specified a runtime for the application. Changing the default will affect all future deployments without a Developer chosen runtime, but will not automatically redeploy workloads using the previous default. Enabled runtimes are available to Developers to select for their applications.

Name, Version, and Path information is editable only for runtime versions added by a Platform Operator. You are not able to change the Name, Version, and Path information for System runtimes, which are installed by the Platform.

To Delete a runtime version, select the Delete option from the corresponding menu. You cannot delete System versions.

Hosting Container

The Hosting Container table shows you the available containers on the Platform. It gives you the ability to add, edit, or delete JBoss containers or versions of Tomcat other than the ones installed with the Platform.

The following information is displayed for each container.

  • The Name of the hosting container
  • The Container Type
  • Home Path refers to the location of the container binaries on all servers that have the specified container version
  • Default indicates which container the Platform will use for all Java Web Application components that do not have a container specified by a Developer. Deployed Java Web Application workloads are not affected when the default container is changed. Only instances deployed after the default is changed will use the new default as its hosting container
  • The System field indicates the containers installed by the Platform. All Platform Operator added containers are flagged "No".
  • All hosting containers are Enabled for Development Teams to use for their Java Web Application components and cannot be disabled. For more information on the Tomcat versions the Platform ships with, see the Supported Software page.

Add a New Hosting Container

Platform Operators are able to add new containers as needed.

Prerequisites

  • Install the container binaries via a uniform path on all Linux servers the container can be deployed to
  • Create new Deployment Policies to manage where the Platform can deploy the new container
  • Assign execute permissions for all custom hosting container .sh files the Platform will use; otherwise, the container will not start

Once you have completed preparing your Platform for the new container, click New Hosting Container and fill in the following:

  • enter a unique Name of the new container. This name is used by Developers to assign a hosting container to their application component, so it is suggested that you use descriptive names to distinguish between hosting containers
  • choose the Container Type from the dropdown list of supported containers
  • fill in the Home Path to the container binaries. You must use the same path for all Linux servers the Platform could deploy the container to

After creating the hosting container, you can edit it to set the new container as the Default container for the Platform. The default hosting container is used for all deployments where a Developer has not specified a hosting container for the application.

Edit or Delete a Hosting Container

To edit an existing hosting container, click on its corresponding Edit button (or the click on the menu button next to it to display more options).

You can set any hosting container as the Platform Default. The default hosting container is used for all deployments where a Developer has not specified a hosting container for the application.

Name, Container Type, and Home Path information is editable only for runtime versions added by a Platform Operator. You are not able to change the Name, Container Type, and Home Path information for System runtimes, which are installed by the Platform.

Note that you are not able to disable a hosting container in the same way you can disable runtime versions. Developers are able to select any hosting container added to the Platform for use in an application.

To Delete a hosting container, select the Delete option from the corresponding menu. You cannot delete System containers.