Require SE 17 compiler, compile to SE 11 source and target level
by Brian Stansberry
WDYT about doing in main what I did in the EE11 topic branch?
https://github.com/wildfly/wildfly/commit/af6e723a27228884dbc3acdc66be10c...
I did that in EE 11 because we know some EE 11 APIs or impls will require
SE 17. So we need the SE 17 compiler to build with those deps. But we want
our own (WFLY and WFCORE) code to remain SE 11 compatible. So the resulting
binary level must be SE 11 and no language features or SE APIs > 11 can be
used by our own code.
Trying to only do this in the EE11 branch has proven to be a pain, because
a bunch of things like github actions are using SE 11 to build and that
blows up when run against the EE11 branch.
If we did this I'd add a profile that could set the compiler version back
to 11. CI jobs that need to both build the server and run the testsuite on
11 could activate that profile.
Over the course of this year the SE 11 build and test use cases should
become the secondary cases, ones that need special handling Iike activating
a profile. SE 17 should become the 'default, it just works with no special
effort' case. Supporting both EE 10 and 11 in different feature packs is
one reason to keep SE 11 support around, but even with EE 10 our 'typical'
case should become SE 17, not SE 11.
Thoughts?
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
9 months
WildFly 31.0.1 is released
by Brian Stansberry
I've announced WildFly 31.0.1 on wildfly.org/news. Thank you Jeff Mesnil
for doing a great job coordinating this one, and to all who helped,
particularly Flavia Rainone. There were a number of important fixes in this
one, including a number of CVE fixes and a nice mix of fixes for end-user
reported problems.
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
10 months
ACTION REQUESTED: WildFly 32 Features and the Community Feature Process
by Brian Stansberry
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
10 months, 1 week
WildFly 32 Release schedule
by Brian Stansberry
FYI, following is the development schedule for WildFly 32. We're aiming to
continue with our pattern of 4 feature releases per year, with Final
generally coming in January, April, July, October.
WF 32 Beta
Feature freeze -- Wed Mar 20
WF Core release -- Mon Mar 25
Server Tag -- Wed Mar 27
Available on wildfly.org + ancillary deliverables -- Thu Mar 28
WF 32 Final
Code freeze -- Wed Apr 3
WF Core release, complete merging -- Mon Apr 8
Server tag -- Wed Apr 10
Available on wildfly.org + ancillary deliverables -- Thu Apr 11
Misc deliverables not doable by Apr 11 -- Fri Apr 12
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
10 months, 1 week
