WFLY-19762 - Define and document our support for MicroProfile with multiple deployments

Each deployment will have access to config properties defined outside of the deployment (e.g. env vars, system properties, and properties set in the MicroProfile Config subsystem).

Further each deployment may define its own config properties via a META-INF/microprofile-config.properties, or custom ConfigSource and ConfigSourceProvider implementations. These own config properties are local to the deployment, and must only be visible from within this deployment. So if we have A.war and B.war, A.war should not see properties local to B.war and vice versa. Of course, A.war and B.war should have access to their own properties.

Already tested with multiple .war deployment with metrics providers; expanding of the test case can be considered.

Each deployment behaves as if it were deployed on its own, however, metrics contribute to the same metric collector.

Each .war contributes its healthiness checks to the global server healthiness.

When multiple .war archives are deployed, if at least one defines the mp.health.disable-default-procedures config to true, it affects the whole server configuration (as described in "Disabling Default Server Procedures" documentation). This multi-deployment behaviour is not specified in the MicroProfile Health specification.

MP OpenAPI subsystem must install an OpenAPI endpoint and model per host (rather than per deployment) and allow applications to contribute components/paths/etc. during deployment.

"Global" properties of the OpenAPI model that are not concordant between applications will be provided by the following host-specific MP Config properties:

All existing extensions will continue to be supported (as verified by existing integration tests)

The MicroProfile Rest Client is a client side only API which creates proxy clients for interacting with REST end points. Given the underlying required API’s are Jakarta EE API’s, Jakarta Context and Dependency Inject and Jakarta REST, there is not much that needs to be done to ensure this works.

This also requires MicroProfile Config. No changes in the implementation are needed to have this work with multiple deployments.

There are no explicit tests for multiple war deployments, but ContextPropagationTestCase does deploy two separate OpenTelemetry applications to test the propagation functionality, so multiple apps are tested implicitly

Explicit tests should be added, though, for a clearer, intentional verification of support: https://issues.redhat.com/browse/WFLY-20626

As a MicroProfile spec, any issues/concerns regarding MicroProfile Config will have relevance here, as the MicroProfile Telemetry spec explicitly depends on Config.

While not technically part of MicroProfile, we do include this in the discussion due to the obvious overlap.

There is already a set of tests that explicitly test multiple application deployment in WildFly, so this functionality is covered and verified as working.

MicroProfile JWT is built upon multiple Jakarta EE and MicroProfile APIs which are already engineered to be isolated per deployment. Security settings in WildFly are already deployment scoped.

To provide further isolation, the JWT integration within WildFly makes use of dynamically instantiated virtual security domains which are created on demand for deployments secured using JWT.

Configuration of JWT for a deployment is scoped to the deployment using MicroProfile Config.

A test will be created with two .war deployments. It will demonstrate that properties coming from outside the deployment are usable by both deployments, and that properties defined within each deployment are local to that deployment.

A test exists in the WildFly testsuite with two .war deployments with different metrics providers, verifying that the basic MP functionality and the corresponding metrics collection works as expected.

The test for MicroProfile FT in the MicroProfile test suite will be enhanced to split the current tests, so that each participant is deployed in a separate war

The existing test deploys two similar applications. In one of them MicroProfile Config properties are used to map the Reactive Messaging channels to AMQP, and in the other the MicroProfile Config properties are used to map the channels to Kafka. A lot of the properties share their names, and the test checks that deployment A sends and receives data to/from AMQP, and that deployment B does the same with Kafka.

No tests are required.

A possible test could be to expand the existing WildFly ReactiveStreamsOperatorsInjectedReactiveEngineProviderSanityTestCase and ReactiveStreamsOperatorsNoReactiveEngineProviderSanityTestCase tests so they deploy two copies of the application, however I don’t think that is necessary.

Add new test that verifies:

A test will be created which deploys two WAR’s. The test will ensure the clients see their own configuration and work.

A test will be added which deploys two applications, each with its own observability support.

The test will verify that each application’s signals are correctly published

The test will also verify that duplicate signal names do not conflict in the system or the export (i.e., tags successfully and correctly differentiate between the deployments' signals)

This scenario is already covered and no additional testing needs have been identified at this time

Existing test cases focus on cases where end users wish to bypass the per deployment isolation for JWT activation and configuration, a new test case JWTParallelDeploymentTestCase will be added which will deploy two applications, each application will use distinct keys and the test case will verify that the use of the keys can not cross over between the two applications.

By design LRA is intended to support multiple participants working against one coordinator. These may all be in different .war files. Only one coordinator can be deployed, while several participants can be deployed. The participants do not interfere with each other

The test for MicroProfile LRA in the MicroProfile test suite will be enhanced to split the current tests, so that each participant is deployed in a separate war