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, 4 months
Upcoming 23.0.1 Release
by Brian Stansberry
It's coming up on a month since WildFly 23, so it's time to do a 23.0.1.
I'd like to tag it next Wed April 7 and have it available for download on
April 8.
We've been porting a number of fixes to the 23.x branch over the last few
weeks. Component leads -- if there are further critical fixes that need to
go into 23.0.1 that haven't gone into 23.x yet, please get JIRAs and PRs
filed ASAP and reply here noting those. I'd like to get things merged by
Monday at the latest.
We've already integrated WildFly Core 15.0.1 into 23.x so I do not
anticipate further changes coming through core.
Best regards,
Brian
3 years
Adding YAML support for configuration customization
by Emmanuel Hugonnet
Hello,
I've written a proposal [1] to support YAML configuration files in addition to the current XML configuration files.
Those YAML files wouldn't replace the XML files but could be used to customize a configuration: allowing to add or remove resources,
undefine or redefine attributes.
This configuration would be added on top of the existing XML configuration on boot but wouldn't impact the XML itself (as we would be in
'read-only' mode).
I have currently a PoC with a simple YAML example, and a cost of ~100 ms on boot time, most of it due to the YAML parsing.
Note that I want to leave some resources out of the scope of that feature: adding extension or subystem would be out of the scope since this
should be done at provisioning.
Thanks for your feedback.
Emmanuel
[1]: https://github.com/wildfly/wildfly-proposals/pull/384
3 years
