4:08 p.m.
Last December I posted[1] about the WildFly Feature Development Process
we're implementing. We understand a lot about what that should look like,
but there are still details to clarify. I think the consensus among the
folks who've been looking at it most is that the best way to progress on
doing that is by actually implementing some features at Community, Preview
or Experimental levels and using the work on those to help firm up the
details.
When we rolled this out in December it was really too late to do much of
that for WildFly 31, except for one feature[2] that Emmanuel Hugonnet did.
But it's not too late to do this for WildFly 32, and I know there are a
number of features that are in various states of development that could
likely benefit from the new process and could thereby be included in next
month's WildFly 32 Beta.
I'll list a number of possible candidates below, but there may very well be
others.
ACTION REQUEST: If you have worked on a feature that you'd like included in
WF 32 at Community, Preview or Experimental, please do the following as
soon as possible:
1) Decide what level you think is achievable in a month's time. If you're
not sure, ask about it in this thread or another wildfly-dev list thread,
or in zulip.
2) Update the analysis document for your feature with the 'Stability Level'
section I added to the proposal template.[3] Tick the appropriate box.
3) Preface the title of the relevant WFLY or WFCORE with [Community],
[Preview] or [Experimental]. (This is so this info is prominent in future
release notes.)
4) Preface the feature title (the "= Foo" line) in the analysis adoc file
with [Community], [Preview] or [Experimental]. (This is so this info is
prominent in future views of https://docs.wildfly.org/wildfly-proposals/)
5) Add 32.0.0.Beta1 as the Fix Version for the JIRA.
6) Look at the draft process at [4] and start working on completing the
requirements! Ask questions on this list or zulip to get clarification on
things.
Please use the list or preferably zulip instead of pinging me personally.
We need to work through this as a group and learn from each other.
Here are the features we thought were likely candidates for the new process
*at some point*. AFAIK no one thought much about whether they could be done
in time for WF 32. The devs working them know better about that. But,
please try and be realistic. :) All features require involvement from
multiple people. And again, there may be other good candidates as well;
don't be shy.
These are in no particular order.
* WFCORE-4807 - Add option to route log messages based on the current
thread's class loader
* WFLY-13762 - SSLContext to support delegation to alternate instances
based on peer information.
* WFLY-14559 - Add four new RESTEasy context parameters
* WFLY-14735 - Add support with the web console for FORM based
authentication resulting in an authenticated session.
* HAL-1831 - Activate form-based authentication in the console
* WFLY-15495 - Add support for gRPC
* WFLY-13530 - REST Integration with grpc (high performance, open-source
universal RPC framework)
* WFLY-16345 - Add support for SFSB externalization to remote Infinispan
server via HotRod
* WFLY-13412 - Add Json Merge Patch support
* WFCORE-4868 - Introduce aliases for standard configuration files
* WFCORE-5279 - Split Elytron SSL into its own subsystem and layer
* WFLY-13828 - remote+tls is not supported by EJBClient and
remote-outbound-connection
* WFLY-15452 - Modify ajp-listener to allow specifying
AJP_ALLOWED_REQUEST_ATTRIBUTES_PATTERN
* WFLY-14255 - Make reuseXForwarded and rewriteHost configurable
* WFLY-17676 - Add a configuration for enabling EE namespace
interoperability
* WFLY-17180 Failure to set query timeout for validation may result in long
blocks of the pool
Note that my emphasis here is on WF 32, but it's ok to start on this with
features where you may not think getting done by the March 20 feature
freeze is realistic, particularly the 'pick a target stability level and
record it in JIRA and analysis' tasks I mentioned above. Just be conscious
that answering your questions etc may be a lower priority over these next
few weeks.
[1]
https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/...
[2] https://issues.redhat.com/browse/WFCORE-4758
[3]
https://github.com/wildfly/wildfly-proposals/blob/main/design-doc-templat...
[4]
https://docs.google.com/document/d/15_yKhW74-X9s2zUhs_ZUuZ3h-RlMfH5xWmHHs...
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His