Add natives for ARM64 to Wildfly distro
by Julien Faye
Hello Wildfly devs,
At my job we want to move to Linux ARM64 machines for our deployments.
The issue we see is that the current (22.0.1) distribution does not include
native binaries for linux-aarch64 architecture :-/
$ find ./ -name "*.so"
./modules/system/layers/base/org/apache/activemq/artemis/journal/main/lib/linux-i686/libartemis-native-32.so
./modules/system/layers/base/org/apache/activemq/artemis/journal/main/lib/linux-x86_64/libartemis-native-64.so
./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-x86_64/libwfssl.so
./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-s390x/libwfssl.so
I've found https://issues.redhat.com/browse/WFLY-13302 (and
https://issues.redhat.com/browse/WFSSL-32 and
https://issues.apache.org/jira/browse/ARTEMIS-2705) but those are opened
almost an year ago and it is not clear whether they will be resolved any
time soon.
As far as I understand your recommendation is to build the binaries
locally. This is OK but it adds some extra complexity to the deployment and
upgrade processes.
Since ARM64 becomes more and more popular for server side deployments I
would like to ask you whether those tickets could be resolved in near
future ?
Thank you!
Regards,
Julien
2 years, 5 months
Progress toward WildFly support for JDK 17 -- Avoiding JPMS problems
by Brian Stansberry
For the last month we've been focusing quite a bit of energy toward seeing
what it will take for WildFly to run well on the upcoming JDK 17. This post
is one of two I plan. This one is an attempt to start a discussion around a
couple topics; the other will be more of a status update.
Status summary is things are progressing well, no show-stoppers so far, but
plenty more to do. More on that in the other post....
WF 23 runs well on SE 13. We want to get to 17. The key barriers are:
1) SE 14 dropped the java.security.acl package.
2) SE 15 introduced hidden classes (JEP 371)
3) SE 16 strongly encapsulated JDK internals by default (JEP 396)
The discussion points relate to #3. WildFly does quite a lot reflection
stuff, plus we have some use cases where end users may want to use internal
JDK classes. SE 16 locks this down. For a good primer on the basic things
SE allows us when we need things to be made available, see [1]. Richard
Opalka did a lot of good analysis of what JPMS-related VM launch settings
we need for WF to work properly; see [2] and [3]. It's not a huge set,
which is nice.
But, it's not complete, because it doesn't account for user applications.
If application code requires additional deep reflection, then additional VM
launch settings will be needed. I think that's ok in general; we provide
hooks for users to add things to the JAVA_OPTS flags that are passed to
java. But the less users need to do that the better. Hence the discussion
topics:
1) The ClassReflectionIndex[4] constructor iterates over all fields and
methods in a class and marks them as accessible. For any class that is used
as an EE component type, *as well its superclasses*, a ClassReflectionIndex
is created. This means if an application uses some JDK class as a
superclass (ignore Object, which gets some special handling that makes it
not a problem in this discussion), then that superclass's package is going
to need to be opened. We have no way to know what superclasses our users'
component might have, so we can't open them up in for them as part of our
standard launch args.
My general understanding is we do this in order to allow things like
injection of values into fields or wrapping calls to non-public methods
with interceptors.
Is there anything we can do about this? Any intelligence we can apply to
avoid doing unnecessary opening? (See [5] for a very specific example of
such a thing.)
Or is this maybe not a big problem? We already need to open the java.util
package for other reasons, so EE component based on classes in that package
won't have a problem.
2) There are cases where our configuration allows users to specify a class
to use as the impl of interface, as an instruction for the server to
instantiate an instance and use it. Examples include NamingContext and
java.security.Policy impls. In some cases well known examples of those
interfaces are internal JDK classes.
Should we identify likely cases of these things and proactively include
those packages in our server launch --add-opens set? My general instinct is
no, but there may be cases where my instincts are wrong.
[1] https://nipafx.dev/five-command-line-options-hack-java-module-system/
[2] https://issues.redhat.com/browse/WFCORE-5406
[3] https://github.com/wildfly/wildfly-core/pull/4591
[4]
https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
[5] https://github.com/wildfly/wildfly/pull/14303
Best regards,
Brian
2 years, 12 months
WildFly 24 Development Schedule
by Brian Stansberry
Here's the schedule I'd like to shoot for as we work on WildFly 24. This
is basically three months after WildFly 23, and lines us up to do 25 in
mid-September (so the final polishing after the typical summer vacations)
and then 26 in early December (before things slow down at year end.)
Fri May 21 -- Core Feature Freeze
Wed May 26 -- Feature freeze / WF 24 Beta1 Tag
Fri Jun 4 -- WildFly Core code freeze
Wed Jun 9 -- WF 24 tag
Thu Jun 10 -- WF 24 available on wildfly.org
Best regards,
Brian
2 years, 12 months
Progress toward WildFly support for JDK 17 -- Status update
by Brian Stansberry
For the last month we've been focusing quite a bit of energy toward seeing
what it will take for WildFly to run well on the upcoming JDK 17. This post
is the second of two I plan. The first was an attempt to start a discussion
around a couple topics; this one will be more of a status update.
Status summary is things are progressing well, no show-stoppers so far, but
plenty more to do.
WF 23 runs well on SE 13. We want to get to 17. Issues we've faced include:
1) SE 14 dropped the java.security.acl package.
2) SE 15 introduced hidden classes (JEP 371)
3) SE 16 strongly encapsulated JDK internals by default (JEP 396) (see [1]
for a nice primer)
4) Some components (i.e. ones to bytecode manipulation) have static maximum
SE versions they support, requiring upgrades to versions that support 17.
The big problem with 1) is the remaining use of Picketbox. Work continues
on eliminating any requirement to use PB. Before standard WildFly can
support SE 17 we'll need to change our standard configs to not require PB.
Work on that is in progress and needs to accelerate this summer as we work
on WF 25.
Meanwhile a lot of our testing focus is on WF Preview, which already
doesn't require use of PB. Our testing of WF Preview already runs over
5,000 tests, so we can identify a lot of issues by running it. We've set
up 3 nightly test jobs to run test WF Preview using SE 15[2], 16[3], and
17[4]. We can also run the EE 9.1 TCK against WF Preview, resulting in over
75K tests being run.
Following yesterday's WF Core upgrade, results are looking pretty decent --
111 failures out of over 5200 tests on [4], with the bulk of those brand
new (so hopefully something crept in yesterday that's easily fixed) and a
number of others with known causes that are being worked.
The JEP 396 change (issue 3 above) is the main subject of my other post.
I'll just say here that Richard Opalka did a lot of research which resulted
in [5] and [6], a set of VM launch settings that allow WF to run reasonably
on SE 16+. Those came into master yesterday.
Having those in means we run well enough that analyzing results from
running the EE 9.1 TCk with SE 17 starts to be worthwhile. A run last night
showed 305 failures in the platform and standalone jaxb TCKs (out of over
71K tests), with explanations / likely solutions available for at least 100
of those. So pretty good.
[1] https://nipafx.dev/five-command-line-options-hack-java-module-system/
[2] https://ci.wildfly.org/viewType.html?buildTypeId=WF_Ee9LinuxJdk15
[3]
https://ci.wildfly.org/viewType.html?buildTypeId=WF_WildFlyPreviewLinuxJdk16
[4]
https://ci.wildfly.org/viewType.html?buildTypeId=WF_WildFlyPreviewLinuxJdk17
[5] https://issues.redhat.com/browse/WFCORE-5406
[6] https://github.com/wildfly/wildfly-core/pull/4591
Best regards,
Brian
3 years
