Staging to vNext 23.0.0.12 issues

modules/ROOT/pages/admin-center.adoc

@@ -67,6 +67,8 @@ For example, if your browser is running on the same computer as your server and
 
 `https://localhost:9443/adminCenter`
 
+Access to Admin Center is supported only when the access comes directly from a browser. Access through an HTTP proxy server is not supported.
+
 If your browser prompts you to confirm that the connection is trusted, specify an exception or otherwise enable the connection to continue to Admin Center.
 To log in to Admin Center, specify the username and password from your management role configuration. For example, if you use the previously provided example `server.xml` configuration, specify `admin` as the username and `adminpwd` as the password.
 

modules/ROOT/pages/instanton-limitations.adoc

@@ -1,4 +1,4 @@
-// Copyright (c) 2022 IBM Corporation and others.
+// Copyright (c) 2022, 2023 IBM Corporation and others.
 // Licensed under Creative Commons Attribution-NoDerivatives
 // 4.0 International (CC BY-ND 4.0)
 //    https://creativecommons.org/licenses/by-nd/4.0/
@@ -23,6 +23,7 @@ The following sections describe the limitations and known issues with using Open
 - <<#trans-before, Jakarta Transaction before checkpoint>>
 - <<#mp-config, Accessing MicroProfile Configuration too early>>
 - <<#datasource, Injecting a DataSource too early>>
+- <<#mp-config-no-default, Accessing MicroProfile Config properties with no default value at checkpoint>>
 - <<#features, Using product extensions, user features, or features that are not supported by InstantOn>>
 - <<#boot,Updating configuration with a bootstrap.properties file>>
 - <<#securitymanager, Java SecurityManager is not supported>>
@@ -161,6 +162,73 @@ This configuration uses placeholder values for things like the database name, ho
 
 If an application is injected with a `DataSource` before the checkpoint and the configuration of the `DataSource` changes, the application is restarted when the InstantOn application container image is run with the updated configuration. You can avoid this scenario by using the `beforeAppStart` option or by modifying the component not to be early startup code. In this example, that modification is to remove the `loadOnStartup = 1` attribute.
 
+[#mp-config-no-default]
+== Accessing MicroProfile Config properties with no default value at checkpoint
+An application injected with a configuration property that has no default value set in any configuration source might cause errors during checkpoint. This section provides solutions for common errors that are encountered.
+
+A configuration property can be introduced into the application either statically or dynamically, and in either case, the property can be declared optional. The following example shows ways to inject static, static-optional, dynamic, and dynamic-optional configuration properties. 
+[source,java]
+----
+  @Inject
+  @ConfigProperty(name = "static_config")
+  String staticConfig;
+
+  @Inject
+  @ConfigProperty(name = "static_optional_config")
+  Optional<String> staticOptionalConfig;
+
+  @Inject
+  @ConfigProperty(name = "dynamic_config")
+  Provider<String> dynamicConfig;
+
+  @Inject
+  @ConfigProperty(name = "dynamic_optional_config")
+  Provider<Optional<String>> dynamicOptionalConfig;
+----
+If no value is found in an existing configuration source during checkpoint, the injected `static_config` property causes an error similar to the following example:
+
+[source,sh]
+----
+SRCFG02000: Failed to Inject @ConfigProperty for key static_config into io.example.Example.staticConfig since the config property could not be found in any config source.
+----
+
+You can avoid this error by providing a default value for the configuration key in one of the following ways:
+
+Specify the default value on the `@ConfigProperty` annotation::
+[source,java]
+----
+  @Inject
+  @ConfigProperty(name = "static_config", defaultValue = "defaultValue")
+  String staticConfig;
+----
+
+Specify the default value in the application `META-INF/microprofile-config.properties` resource::
+[source,sh]
+----
+  static_config=defaultValue
+----
+
+Specify a default value in a `variable` element in the server.xml` file::
+[source,xml]
+----
+  <variable name="static_config" defaultValue="defaultValue" />
+----
+
+If no default value is set, you can still avoid the previous error by injecting configuration with the `static_optional_config`, `dynamic_config`,  or `dynamic_optional_config` properties. 
+However,  the following error might occur if you use the checkpoint option with CDI beans that are `@ApplicationScoped` and the `dynamic_config` is accessed too early during application startup:
+[source,sh]
+----
+java.util.NoSuchElementException: SRCFG00014: The config property dynamic_config is required but it could not be found in any config source.
+----
+Similarly, accessing the `static_optional_config` and `dynamic_optional_config` too early might cause the following error:
+[source,sh]
+----
+java.util.NoSuchElementException: No value present
+----
+
+Therefore, to avoid these errors it is best to set a default value for injected config properties as optional and dynamic config can be accessed too early during application startup. Furthermore, if the `@ConfigProperty` injection site is not using dynamic configuration, then any default value that is injected into the application-scoped bean before checkpoint is not updated on restore. For more information, see xref:#mp-config[Accessing MicroProfile Config too early]
+
+
 [#features]
 == Using product extensions, user features, or features that are not supported by InstantOn
 InstantOn supports only a subset of Open Liberty features, as described in xref:instanton.adoc#supported-features[Open Liberty InstantOn supported features]. Any public features that are enabled outside of the supported set of features for InstantOn cause checkpoint to fail with an error message like the following example:

modules/ROOT/pages/instanton.adoc

@@ -318,6 +318,7 @@ Currently, Open Liberty InstantOn is tested and supported on the following publi
 
 - link:https://aws.amazon.com/eks/[Amazon Elastic Kubernetes Service (EKS)]
 - link:https://azure.microsoft.com/en-us/products/kubernetes-service[Azure Kubernetes Service (AKS)]
+- link:https://www.redhat.com/en/technologies/cloud-computing/openshift[Red Hat OpenShift (version 4.14 and later)]
 
 Other public cloud Kubernetes services might also work if they have the <<#required-to-restore,prerequisites>> to allow the InstantOn application process to restore.
 
@@ -337,6 +338,36 @@ When you deploy to Kubernetes, the container must be granted the `CHECKPOINT_RES
             - ALL
 ----
 
+==== Red Hat OpenShift security context constraints
+
+To deploy applications to Red Hat OpenShift with InstantOn, you must specify a security context constraint (SCC) that, at a minimum, specifies a list of additional capabilities that are added to any pod. The following SSC yaml file example defines an SCC with the required capabilities by using the `defaultAddCapabilities` parameter:
+
+[source,yaml]
+----
+defaultAddCapabilities:
+- CHECKPOINT_RESTORE
+- SETPCAP
+----
+
+The applications you deploy must be associated with an SCC that adds the required capabilities. For example, you might deploy an SCC called `liberty-instanton-scc` that adds the required capabilities. In the following example, the deployment yaml file specifies the `serviceAccountName` parameter to set the SCC name to `liberty-instanton-scc`:
+
+[source,yaml]
+----
+  serviceAccountName: liberty-instanton-scc
+  securityContext:
+    allowPrivilegeEscalation: true
+    privileged: false
+    runAsNonRoot: true
+    capabilities:
+      add:
+      - CHECKPOINT_RESTORE
+      - SETPCAP
+      drop:
+      - ALL
+----
+
+For more information, see the Red Hat documentation for link:https://docs.openshift.com/container-platform/latest/authentication/managing-security-context-constraints.html[Managing security context constraints].
+
 [#supported-features]
 == Open Liberty InstantOn supported features
 

modules/ROOT/pages/jaxrs-integration-cdi.adoc

@@ -15,7 +15,9 @@
 
 In Open Liberty, Jakarta RESTful Web Services (formerly known as JAX-RS) can integrate with the Contexts and Dependency Injection (CDI) specification. By integrating RESTful Web Services with CDI, you can annotate CDI beans or managed beans as REST endpoints and use CDI injection for web services.
 
-In Open Liberty, RESTful Web Services support is enabled by the feature:restfulWS[display=Jakarta RESTful Services feature]. This feature helps applications build and consume RESTful services. It also supports CDI-style beans as root resource classes, providers, and application subclasses. Providers and application subclasses must be singleton classes or use the application scope. The CDI specification helps integrate various kinds of Jakarta EE components in a loosely coupled but type-safe way. This specification provides a common mechanism to inject components, such as enterprise beans or managed beans, into other components, such as Jakarta Server Pages (JSP) files or other enterprise beans. CDI support in Open Liberty is enabled by the xref:reference:feature/cdi-2.0.adoc[Contexts and Dependency Injection feature].
+In Open Liberty, RESTful Web Services support is enabled by the feature:restfulWS[display=Jakarta RESTful Services feature]. This feature helps applications build and consume RESTful services. It also supports CDI-style beans as root resource classes, providers, and application subclasses. Providers and application subclasses must either be singleton classes or use the application scope.
+
+The CDI specification helps integrate various kinds of Jakarta EE components in a loosely coupled but type-safe way. This specification provides a common mechanism to inject components, such as enterprise beans or managed beans, into other components, such as Jakarta Server Pages (JSP) files or other enterprise beans. CDI support in Open Liberty is enabled by the xref:reference:feature/cdi-2.0.adoc[Contexts and Dependency Injection feature].
 
 
 One way to implement CDI with RESTful Web Services resources is to use the `@ApplicationScoped` and `@Inject` annotations with application-scoped beans in your application code, as shown in the following example:
@@ -34,18 +36,19 @@ public class ApplicationScopedResource {
 
 }
 ----
+
 The `@ApplicationScoped` annotation specifies that only one instance of this bean is used for the lifecycle of the application. Normally, RESTful Web Services resources are per-request, which means the RESTful Web Services engine creates a new instance of the class for each HTTP request. Per-request classes are beneficial in some cases but they are generally less efficient than per-application resources, in which the same instance is used for every HTTP request.
 
 The `@Inject` annotation injects an instance of the `SimpleBean` class into the instance of the `ApplicationScopedResource` bean. For more information about CDI, see xref:cdi-beans.adoc[Context and Dependency Injection beans].
 
 
 == RESTful Web Services and CDI scopes
 
-The scope of a bean defines the lifecycle of its instances. A bean lifecycle can be singleton, so that the same instance is used for every HTTP request, or per-request, so that a new instance is created for each HTTP request. Bean lifecycles can also be scoped to a particular session, or by conversation, which is defined by explicit developer-controlled boundaries for JSF applications.
+The scope of a bean defines the lifecycle of its instances. A bean lifecycle can be singleton, so that the same instance is used for every HTTP request, or per-request, so that a new instance is created for each HTTP request. Bean lifecycles can also be scoped to a particular session, or by conversation, which is defined by explicit developer-controlled boundaries for Jakarta Server Faces (JSF) applications.
 
 RESTful Web Services and CDI specify slightly different scopes. If the lifecycle scopes that are specified by RESTful Web Services and CDI are in conflict, the resulting lifecycle depends on the component type of the RESTful Web Services resource. RESTful Web Services provider component types are always singletons, regardless of the CDI annotation. RESTful Web Services resource component types adopt whatever lifecycle is specified by the CDI annotation.
 
-For example, the `ApplicationScoped` CDI scope annotation defines a singleton lifecycle, because only one instance of a class with this annotation is used for the lifecycle of the application. If you configure a RESTful Web Services resource scope as per-request, but then specify the `@ApplicationScoped` CDI scope on it, the resource lifecycle is singleton. Similarly, if you configure a RESTful Web Services resource scope as singleton, but then specify the `@RequestScoped` CDI scope on it, the resource lifecycle is per-request, as specified by the CDI annotation.
+For example, the `ApplicationScoped` CDI scope annotation defines a singleton lifecycle, because only one instance of a class with this annotation is used for the lifecycle of the application. If you configure a RESTful Web Services resource scope as per-request, but then specify the `@ApplicationScoped` CDI scope on it, the resource lifecycle is singleton. Similarly, if you configure a RESTful Web Services resource scope as a singleton class, but then specify the `@RequestScoped` CDI scope on it, the resource lifecycle is per-request, as specified by the CDI annotation.
 However, if the RESTful Web Services component is a provider, the lifecycle is singleton, regardless of the CDI annotation.
 
 For more information, see xref:cdi-beans.adoc#_cdi_scopes[CDI scopes].
@@ -56,8 +59,8 @@ CDI with RESTful Web Services in Open Liberty is subject to the following restri
 
 - If the Contexts and Dependency Injection feature is not enabled in your `server.xml` file, the runtime has no CDI support. Therefore, if you specify a  CDI annotation in a Java class, the RESTful Web Services engine uses the Java class as a plain old Java object (POJO) class.
 - If a resource class with the `@Path` annotation implements a RESTful Web Services provider interface or declares with the `@Provider` annotation, then this class works as both a resource and a provider. In this case, the RESTful Web Services engine uses only one instance of this class that is shared by the resource class and the provider. The lifecycle of the instance is singleton.
-- If a RESTful resource is also a CDI-managed bean and its scope is `javax.enterprise.context.Dependent`, the `PreDestroy` method cannot be called because of the CDI restriction.
-- If a class is registered in both the `getClasses` and `getSingletons` methods of the application class, the RESTful Web Services engine uses the instance from the `getSingletons` method and ignores the `getClasses` instance. However, objects that are returned in the `getSingletons` method are not managed by CDI. In general, avoid use of the `getSingletons` method as it is targeted for deprecation and eventual removal from future versions of the RESTful Web Services specification.
+- If a RESTful resource is also a CDI-managed bean and its scope is `jakarta.enterprise.context.Dependent`, the `PreDestroy` method cannot be called because of the CDI restriction.
+- If a class is registered in both the `getClasses` and `getSingletons` methods of the application class, the RESTful Web Services engine uses the instance from the `getSingletons` method and ignores the `getClasses` instance. However, objects that are returned in the `getSingletons` method are not managed by CDI. In general, avoid use of the `getSingletons` method.
 
 == See also
 - Guide: link:/guides//cdi-intro.html[Injecting dependencies into microservices]