---
# Add any category for this proposal as a YAML list, e.g.
# - core
# - management
# If missing, add it to _data/wildfly-categories and use its id
categories:
# Specify the stability level of the feature.
# Values can be one of: experimental, preview, community, or default
stability-level:
# Specify the Feature Development tracker issue for the feature.
# This must be an issue tracked in https://github.com/orgs/wildfly/projects/7/views/1.
# To create a Feature Development tracker issue, go to https://github.com/wildfly/wildfly-proposals/issues/new/choose
# and select 'Feature Development'
issue:
# Provide the GitHub ids of the feature team members, organized by role.
# Provide a single id for the 'assignee' role. Use a YAML list for the 'sme' and
# 'outside-perspective' roles, even if there is only one person in a role.
feature-team:
 developer:
 sme:
  -
 outside-perspective:
  -
# If this issue tracks the promotion of a previously completed feature to a higher stability level, provide the URL of
# the original https://github.com/wildfly/wildfly-proposals/issues issue that was used to track the implementation of
# that feature.
promotes:
# During initial development of a feature, this field should be left blank. If after the feature is completed and its
# stability level is promoted via a later issue, the developer promoting the issue should return to this document ("this"
# being the original analysis document for the feature). The field should be updated to point to the
# https://github.com/wildfly/wildfly-proposals/issues issue that promotes it.
# For example,
#              | Implementation Issue (A) | Promotion Issue (B)
# promotes:    |                          | https://github.com/.../A
# promoted-by: | https://github.com/.../B |
promoted-by:
---

= <INSERT TITLE HERE>
:author:            Your Name
:email:             your.email@redhat.com
:toc:               left
:icons:             font
:idprefix:
:idseparator:       -

__<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.>__

=== User Stories

__<Provide one or more brief user stories that illustrate the intended users of the feature and the goal they will seek
to achieve by using the feature.>__

== Issue Metadata

=== Related Issues

__<List the issues related to this feature>__

=== 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 that 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 fulfilled by this feature.>__

__<For analyses of a promotion of an existing feature to 'preview' or 'community' stability, only list new requirements;
existing requirements from the feature being promoted are assumed to continue unless otherwise noted in the 'Changed
requirements' section. Other analyses, including those for promotion to the 'default' stability level, must list all
requirements.>__

=== Changed requirements

__<Only relevant for analyses of a promotion of an existing feature to 'preview' or 'community stability. Other analyses
should remove this section.>__

__<For any existing requirements from the feature being promoted that are being changed or removed, describe the change.>__


=== 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

__<Does the proposed work change the default value of any current configuration attributes? Does it change the
configuration generated by any current Galleon layers?>__

=== Importing Existing Configuration

__<Does the proposed work affect the ability to run WildFly running an existing configuration? Is there anything else
about the proposed work that may require changes to the WildFly server migration tool?>__

=== Deployments

__<Does this feature change the behavior of deployments in incompatible ways? If yes, please detail what is the deployment
issue observed when no change is done, and what is the change needed to solve the deployment issue.>__

=== Interoperability

__<Is this feature impacting interoperability?>__

== Implementation Plan

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

== Admin Clients

__<Identify the level of compatibility this feature will have with the existing admin clients (JBoss CLI and the Admin
Console / HAL). Identify any follow-up work that will be required in the clients and link issues created to track this work.>__

== Security Considerations

__<What impact on security does this feature have?>__

__<For features introducing new management API resources, attributes, or operations, if anything other than 'typical' RBAC behavior is required, the Requirements section should include detailed requirements. For example, 'For management RBAC purposes, the foo resource will be marked as security-sensitive for access, reads, and writes.' The typical RBAC behavior is: any authenticated management user can access and read, while writes are limited to Maintainer or higher and runtime operation execution is limited to Operator and higher. Anything involving the security configuration of the server should be marked as security-sensitive. The https://github.com/wildfly/wildfly-core/blob/main/controller/src/main/java/org/jboss/as/controller/access/constraint/SensitivityClassification.java file lists the reasons something may be security sensitive. Most are specific to specific things, but ones that may be relevant to new things include: 

1) 'CREDENTIAL', which must be used for any attribute that holds any kind of authentication credential (not just a password) 
2) The various 'XXXX_REF' classifications, which must be used for configuration attributes that hold model references to security-relevant capabilities. This include SOCKET_BINDING_REF for any socket-binding attribute.
3) 'SOCKET_CONFIG' for things that configure in-bound or out-bound sockets.

See also https://docs.wildfly.org/39/Admin_Guide.html#configuring-constraints and https://docs.wildfly.org/39/Admin_Guide.html#classifications-with-broad-use.>__

[[test_plan]]
== Test Plan

__<Depending on the selected stability level, the appropriate section below should be completed, including a brief
description of how testing is to be performed in accordance with the selected stability level. The non-relevant sections
may be removed as needed.>__
////
Depending on the stability level, the test plan required may vary. See below.
////

** Experimental - No test plan is required. Basic unit / integration tests should be added during development.

** Preview - a brief high-level description of the testing approach should be added here, including types of tests added
(unit, integration, smoke, component, subsystem, etc.) Note that not all test types are required for a particular feature,
so include a description of what is being tested and the approach chosen to perform the testing.

** Community - this level should include everything in the 'Preview' stability level, plus the following additional testing as relevant:
*** Manual tests: briefly describe checks to be performed during one-time exploratory testing. The purpose of this testing
is to check corner cases and other cases that are not worth implementing as automated tests. Typical checks are: bad
configurations are easy to reveal, attribute descriptions and error messages are clear, names are descriptive and consistent
with similar resources, default values are reasonable. If there is an existing quickstart affected by the feature, manual
checks include following the quickstart's guide and verifying functionality.
*** Miscellaneous checks: Manual checks for significant changes in server performance, memory and disk footprint should
be described here. These checks are not always relevant, but consideration of these impacts, and others, are strongly
encouraged and should be described here. Fully qualified test case names should be provided along with a brief description
of what the test is doing.
*** Integration tests - At the 'Community' stability level, complete integration tests should be provided.
*** Compatibility tests - If backwards compatibility is relevant to the feature, then describe how the testing is performed.
** Default - This stability level is reserved and requires approval by a professional Quality Engineer with subject matter expertise.

== Community Documentation

__<Describe how this feature will be documented or illustrated. Generally a feature should have documentation as part of
the PR to wildfly main, 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.>__