[]  <INSERT TITLE HERE>

In 
Tracked by 

<The entire document should be one to two pages long. We will write each analysis document as if it is a conversation with a future developer. This requires a good writing style, with full sentences organized into paragraphs. Bullets are acceptable only for visual style, not as an excuse for writing sentence fragments.>

Overview

<Define the requirement here. Be clear and succinct, you should be able to clearly define the context or problem in two or three paragraphs (if not sentences). Try to define the problem in the overall context and not to get into too much technical detail at this point.>

Affected Projects or Components

<List the projects or components that are affected by the feature. List them using their Git repositories.>

Other Interested Projects

Relevant Installation Types

<List the installation types thar are relevant for the features and remove any that are not relevant>.

  • Traditional standalone server (unzipped or provisioned by Galleon)

  • Managed domain

  • OpenShift Source-to-Image (S2I)

  • Bootable jar

Requirements

<Describe the requirements that must be fullfilled by this feature.>

Non-Requirements

<Use this section to explicitly discuss things that readers might think are required but which are not required.>

Future Work

<Use this section to discuss requirements that are not addressed by this proposal but which may be addressed in later proposals.>

Backwards Compatibility

<Does this enhancement affect backwards compatibility with previously released versions of WildFly? Can the identified incompatibility be avoided?>

Default Configuration

<What is the impact of this feature in the default configuration(s) provided by WildFly?>

Importing Existing Configuration

TBD

Deployments

<Does this feature change the behavior of deployments in incompatible ways?>

Interoperability

<Is this feature impacting interoperability?>

Implementation Plan

<This section is optional. If you have a complex feature which can not be delivered all in one go, suggest the strategy.>

Security Considerations

<What impact on security does this feature have?>

Test Plan

<How do you plan to test this feature?>

Documentation Plan

<Describe how this feature will be documented or illustrated. Generally a feature should have documentation as part of the PR to wildfly master, or as a follow up PR if the feature is in wildfly-core. In some cases though the feature will bring additional content (such as quickstarts, guides, etc.). Indicate which of these will happen>

Release Note Content

<Draft verbiage for up to a few sentences on the feature for inclusion in the Release Note blog article for the release that first includes this feature. Example article: https://www.wildfly.org/news/2024/01/25/WildFly31-Released/. This content will be edited, so there is no need to make it perfect or discuss what release it appears in.>