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, 11 months
Future of WildFly Docker image
by Jean-Frederic Mesnil
Hi,
As you know, WildFly is providing a Docker image for each release of WildFly from the jboss organization at https://hub.docker.com/r/jboss/wildfly/tags.
However hub.docker.com has recently changes their features and we are no longer able to automate new images whenever we tag our GitHub project at https://github.com/jboss-dockerfiles/wildfly. This is becoming a manual task that only a few people in jboss organization can do.
We are trying to find a new way to deliver these images in a sustainable fashion.
One approach would be to move the Docker images to quay.io which provides the basic features we need to build images from our GitHub repo.
We already have a wildfly organization on Quay.io (that provides our S2I images as well as the WildFly operator): https://quay.io/organization/wildfly
This would affect users that pulls our images as they would have to
use
FROM quay.io/wildfly/wildfly
instead of
FROM jboss/wildfly
Internally, there would be no changes: we would continue to build these Docker images from tags in https://github.com/jboss-dockerfiles/wildfly
The latest release for our Docker image was the 25.0 tag.
A transition would be:
0. Advertise that we will stop delivering images from hub.docker.com. At this point, the jboss/wildfly:latest tag will point to 25.0 and will no longer be in sync with new WildFly releases.
1. Set up the quay.io/wildfly/wildfly repo and push the 25.0 tag to it.
-> users can switch from "jboss/wildfly” to "quay.io/wildfly/wildfly” without any impact for their applications
1.a If we eventually release images for 25.0.x versions, we will push images to both hub.docker and quay.io repositories
2. When we release the next major version of WildFly (WildFly 26), the image will be made available only from "quay.io/wildfly/wildfly” with the 26.0 and latest tag
Does that approach sounds sensible?
Best regards,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
3 years
Creating -jakarta variants of WildFly artifacts using source transformation
by Brian Stansberry
Last July, I started a thread[1] here about ways to get native jakarta
namespace variants of artifacts, which we need for our move to EE 10. One
of the items discussed there was "5) New maven module, transform source and
build". I'm posting here as a kind of status update and tutorial about that
approach.
At this point there are 11 maven modules in the WildFly main source tree[2]
that are producing artifacts using the approach described there, and there
are PRs open for at least a couple more. I have filed or soon will file
JIRAs[3] for all the remaining WF main tree's modules that produce
artifacts that WildFly Preview currently is transforming when it provisions
a server[4], so there will be more coming.
Overview
The high level overview of how these work is that a pom-only maven module
is created that corresponds to an existing module that produces an javax
artifact. The new module's pom uses the batavia maven plugin[5] (and
Eclipse Transformer under the covers) to find the source code from the
existing maven module, transform it, and write the transformed output to
the target/ dir of the new module, specifically in the
'generated-resources', 'generated-sources', 'generated-test-resources' and
'generated-test-sources' dirs. That generated source is then associated
with the overall maven execution for the module, and thereafter gets
included as part of the subsequent compile, test, package, install and
deploy goals executed for the module. So, presto we have native jakarta
source available that is then compiled and tested and used to
package/install/deploy binary, source and javadoc jars.[6]
The generated source does not get committed into the git repository. The
git repo only has the pom.
It's a common thing for generated source to be used in an artifact build;
for example it's the technique we use to generate implementation classes
from the XXXLogger interfaces we have for each of our subsystems. What
we're doing here just takes this concept to the max by generating 100% of
the source, including test source.
Tutorial
I'm going to use a PR I sent up yesterday to illustrate how to create one
of these:
https://github.com/wildfly/wildfly/pull/14822
Steps:
1) Decide whether the module you want to work on is ready. If you're not
the component lead responsible for the module, ask that lead. To see if a
module is 'ready', look at its compile time dependencies and see if it
still depends on other artifacts for which a native jakarta variant is
needed and doesn't exist yet. Ask here or in zulip if you are not sure!
Things can change quickly, and there also may be some edge cases where
you'd think you need a jakarta namespace dependency but you really don't.
If there are dependencies that are not ready yet, stop and wait until they
are available. Or be prepared for your new module to not build, at which
point you can save your work and wait.
2) Create a new dir under ee-9/source-transform for your new module. If the
module you are transforming isn't directly under the root of the WF source,
then create a matching structure under ee-9/source-transform. For example,
I created ee-9/source-transform/jpa/spi to produce a jakarta.* variant of
jpa/spi.
3) Copy the pom.xml from an *existing source-transform module* into your
new dir. Easiest is to use one that comes from a dir the same # of levels
below source-transform as your new dir, so a couple relative paths in your
new pom are correct. For my PR I copied over
https://github.com/wildfly/wildfly/blob/main/ee-9/source-transform/weld/c...
Don't start with the pom from your source input module. Unless you want to
work out how to adapt it to use the source transformation. :) Granted it's
not rocket science. But it's easier for code reviewers to look at these if
they look like the other ones.
4) Change the artifactId in your new pom to *exactly* match the artifactId
of the module you're transforming, but with "-jakarta" appended:
https://github.com/wildfly/wildfly/pull/14822/files#diff-d9ae5e5e0388bc9e...
5) Change the 'name' tag to something appropriate, like
https://github.com/wildfly/wildfly/pull/14822/files#diff-d9ae5e5e0388bc9e...
6) Change the 'transformer-input-dir' maven property to point to the root
of the module you are transforming:
https://github.com/wildfly/wildfly/pull/14822/files#diff-d9ae5e5e0388bc9e...
This property is used in the batavia maven plugin config in the parent
source-transform dir. Each child module sets the property to point to the
correct input source for that module.
This one small tweak is the only thing you need to deal with to get the
source transformation set up.
7) Configure dependencies.
a) Delete the existing 'dependency' entries in your new pom, as they are
for whatever random file you copied in.
b) Copy over the 'dependency' entries from the pom of the module you are
transforming.
c) For any entries where your new artifact uses a dependency with a
different groupId:artifactId from the one you're transforming, change the
GA. For example:
EE 8 JTA
https://github.com/wildfly/wildfly/blob/25.0.0.Final/jpa/spi/pom.xml#L58
became EE 9.1 JTA
https://github.com/wildfly/wildfly/pull/14822/files#diff-d9ae5e5e0388bc9e...
Or, in another example
an EE 8 based 'ee' subsystem module dep:
https://github.com/wildfly/wildfly/blob/25.0.0.Final/ee-security/pom.xml#L45
became instead a dep on the new '-jakarta' variant:
https://github.com/wildfly/wildfly/pull/14652/files#diff-7ed0e6e85369889b...
d) A nice to have is to separate from the others in the dependency listing
deps where WF Preview is using a different artifact from what standard WF
is using. For example see
https://github.com/wildfly/wildfly/pull/14822/files#diff-d9ae5e5e0388bc9e...
This separation helps code reviewers.
8) Tell your new module's parent to include it in the build:
https://github.com/wildfly/wildfly/pull/14822/files#diff-37dfe0d6acd41e18...
9) The ee-9/pom.xml maintains a dependencyManagement set for all artifacts
that differ in WF Preview from what is in standard WF. These can either be
artifacts whose GA is not used at all in standard WF, or ones where WF
Preview uses a different version. Add your new artifact to this
dependencyManagement:
https://github.com/wildfly/wildfly/pull/14822/files#diff-5ddee375313bf441...
10) Allow re-use of the module.xml that incorporates this artifact between
standard WF and WF Preview. This is done by modifying the module.xml to add
an expression that the maven-resource-plugin replaces when preparing the
module.xml resource file for use in the FP build:
https://github.com/wildfly/wildfly/pull/14822/files#diff-f89017fad51e240c...
The added @module.jakarta.suffix@ gets replaced either with an empty string
(standard WF) or "-jakarta" (WF Preview)
11) Add your new artifact as a dependency of ee-9/feature-pack/pom.xml.
This is needed so the wildfly-preview Galleon feature pack can utilize your
new artifact:
https://github.com/wildfly/wildfly/pull/14822/files#diff-1375aa050fa94d63...
12) Tell the wildfly-preview feature-pack build to ignore the no-longer
relevant javax artifact you're replacing. This saves build time, compute
resources and false positives in the build log that make us think your
artifact hasn't been handled yet.
https://github.com/wildfly/wildfly/pull/14822/files#diff-1375aa050fa94d63...
(Note the precise spot to put that 'exclude' may differ, a bit. Ask if this
is unclear.)
13) Add an entry for your new artifact in the license.xml file for the
wildfly-preview feature back. Put it in the right alphabetical spot based
on its groupId and artifactId.
https://github.com/wildfly/wildfly/pull/14822/files#diff-11ae0f2f274afa8c...
14) Do a build and if good, commit and send up a PR! If your input module
had tests, your new module should as well and they should run. If you're
curious, have a look in the new target/generated-xxx dirs to see the
source..
This sounds like a lot, and I suppose it is, but other than step 7) it's
all very simple stuff, mostly things you'd do any time you add a new module
to the WF source tree. Granted I'm practiced at this, but it took me about
half an hour to work up the PR I've been using as an example.
If you're interested in doing one of these, and the component lead
responsible for the input module is agreeable, please go for it and feel
free to ask for help.
[1]
https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/...
[2] Child modules under
https://github.com/wildfly/wildfly/tree/main/ee-9/source-transform
[3] High level tracker issues for this work are
https://issues.redhat.com/browse/WFLY-15436 and
https://issues.redhat.com/browse/WFLY-15437. I'm filing separate issues for
individual pieces and am linking those to one or the other of these two
trackers.
[4]
https://docs.google.com/spreadsheets/d/1TekfyRb2UBCLqsPQ83WTg8XOw9qwuHVSh...
shows all artifacts (not just those from the WF source tree) that the
WildFly Galleon plugin was transforming in builds on Oct 14. The rows that
end with '-26.0.0.Beta1-SNAPSHOT.jar' are ones that are produced by WildFly
main itself. I add new tabs to that document weekly to track progress on
reducing the # of artifacts being transformed by the Galleon plugin.
[5]
https://github.com/wildfly/wildfly/blob/main/ee-9/source-transform/pom.xm...
[6]
https://repository.jboss.org/org/wildfly/wildfly-mail-jakarta/25.0.0.Final/
which was produced from a maven module with nothing in it but a pom.
Best regards,
--
Brian Stansberry
Project Lead, WildFly
He/Him/His
3 years
Farah Juma is a WildFly merger!
by Brian Stansberry
I'm very pleased to announce that Farah Juma has joined the group of
contributors who can merge changes to the wildfly/wildfly and
wildfly/wildfly-core repos on GitHub (plus a bunch of other associated
repos in the wildfly GitHub org.)
Farah's been a great WildFly contributor for many years now, actively
contributing in many ways to numerous WildFly subsystems and to the
WildFly Core kernel. Among other things this includes coding, writing and
reviewing feature requirements analyses, and lots of code reviews. She's
currently the WildFly component lead in the security areas and for JSF.
She's also the lead for the Elytron project where she does a great job
fostering a healthy community.
Thanks for all your great work, Farah!
Best regards,
--
Brian Stansberry
Project Lead, WildFly
He/Him/His
3 years
Micrometer Support in WildFly
by Jason Lee
For (hopefully) WildFly 26, we're planning on including out-of-the-box
support for Micrometer metrics. We're still discussing all of the various
implications of that, and we'd love to have anyone interested join us. If
you'd like more details, please see my latest blog post here:
https://jasondl.ee/posts/2021/wildfly-and-micrometer.html
Jason Lee
Principal Software Engineer
Red Hat JBoss EAP
3 years
Thank you! JDK 18 Early Access build 20 is now available
by Rory O'Donnell
Hi David & Richard,
*Thank you.*
I'm retiring at the end of November 2021, it's time to spend more time
with the family.
We started the Quality Outreach back in October 2014. We now have 170+
projects participating.
Thank you for taking the time to provide Testing feedback , excellent
bugs and support throughout
the last seven years.
It's been a pleasure working with you. I am delighted to say that the
program will continue
with the support of the Java DevRel Team, with David Delabassee as your
contact. David has
been assisting with on-boarding new projects for the last couple of years.
All the best, Rory
*OpenJDK 18Early Access build 20is now available
at**https://jdk.java.net/18/ <https://jdk.java.net/18/>**
*
* These early-access , open-source builds are provided under the
o GNU General Public License, version 2, with the Classpath
Exception <https://openjdk.java.net/legal/gplv2+ce.html>.
* Release Notes are available athttps://jdk.java.net/18/release-notes
<https://jdk.java.net/18/release-notes>
* Features:
o JEPs integrated to JDK 18, so far:
+ JEP 400: UTF-8 by Default <https://openjdk.java.net/jeps/400>
+ JEP 408: Simple Web Server <https://openjdk.java.net/jeps/408>
+ JEP 413: Code Snippets in Java API Documentation
<https://openjdk.java.net/jeps/413>
o JEPs targeted to JDK 18, so far
+ JEP 417: Vector API (Third Incubator)
<https://openjdk.java.net/jeps/417>
o JEPs proposed to target JDK 18:
+ JEP 416: Reimplement Core Reflection with Method Handles
<https://openjdk.java.net/jeps/416>
* Significant changes since the last availability email:
o Build 20:
+ JDK-8275252: Migrate cacerts from JKS to password-less PKCS12
+ JDK-8275149: (ch) ReadableByteChannel returned by
Channels.newChannel(InputStream) throws ReadOnlyBufferException
+ JDK-8266936: Add a finalization JFR event
+ JDK-8264849: Add KW and KWP support to PKCS11 provider
o Build 19:
+ JDK-8274840: Update OS detection code to recognize Windows 11
+ JDK-8274407: (tz) Update Timezone Data to 2021c
+ JDK-8273102: Delete deprecated for removal the empty
finalize() in java.desktop module
o Build 18:
+ JDK-8274656: Remove default_checksum and safe_checksum_type
from krb5.conf
+ JDK-8274471: Add support for RSASSA-PSS in OCSP Response
+ JDK-8274227: Remove "impl.prefix" jdk system property usage
from InetAddress
+ JDK-8274002: [win11 and winserver2022] JDK executable
installer from network drive starts with huge delay
+ JDK-8273670: Remove weak etypes from default krb5 etype list
o Build 17:
+ JDK-8273401: Disable JarIndex Support In URLClassPath
+ JDK-8231640: (prop) Canonical property storage
+ Build 16:
+ JDK-8269039: Disable SHA-1 Signed JARs
*Topics of Interest:*_
_
_JDK 17:_**
**
* *Inside Java Podcast “Java 17 is Here!”*
o *Part 1: https://inside.java/2021/09/14/podcast-019/
<https://inside.java/2021/09/14/podcast-019/>*
o *Part 2: https://inside.java/2021/09/27/podcast-020/
<https://inside.java/2021/09/27/podcast-020/>*
* *G1 GC & Parallel GC Improvements in JDK 17*
o *https://inside.java/2021/09/17/jdk-17-gc-updates/
<https://inside.java/2021/09/17/jdk-17-gc-updates/>*
* ZGC - What's new in JDK 17**
o *https://inside.java/2021/10/05/zgc-in-jdk17/
<https://inside.java/2021/10/05/zgc-in-jdk17/>*
* JDK 17 Security Enhancements**
o *https://inside.java/2021/09/15/jdk-17-security-enhancements/
<https://inside.java/2021/09/15/jdk-17-security-enhancements/>*
* The Vector API in JDK 17 (video)**
o *https://inside.java/2021/09/23/devlive-vector-api/
<https://inside.java/2021/09/23/devlive-vector-api/>*
* Faster Charset Encoding**
o *https://inside.java/2021/10/17/faster-charset-encoding/
<https://inside.java/2021/10/17/faster-charset-encoding/>*
_JDK 18:_
* JEP 400 and the Default Charset
o https://inside.java/2021/10/04/the-default-charset-jep400/
<https://inside.java/2021/10/04/the-default-charset-jep400/>
* JDK 18 augmented `javac -Xlint:serial` checks
o https://inside.java/2021/10/20/augmented-serial-checks
<https://inside.java/2021/10/20/augmented-serial-checks/>
_Project Panama - Foreign Function & Memory API:_
* Finalizing the Foreign APIs
o https://inside.java/2021/09/16/finalizing-the-foreign-apis/
<https://inside.java/2021/09/16/finalizing-the-foreign-apis/>
* Resource Scope Dependencies
o https://inside.java/2021/10/12/panama-scope-dependencies/
<https://inside.java/2021/10/12/panama-scope-dependencies/>
***October 2021 Critical Patch Update Released*
* As part of the October 2021, we released JDK 17.0.1 LTS, JDK 11.0.13
LTS, JDK 8u311 and JDK 7u321 as well as OpenJDK 17.0.1 (publicly
available).
Rgds,Rory
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
3 years
Nightly CI
by Brian Stansberry
Ken Wills and I did a bit of organizing of the nightly CI jobs for full
WildFly.
Ken created a new 'Main - Nightly Jobs' subproject for them and moved them
from the root project. Then I renamed most of the jobs. Primarily to
replace use of 'Master' or 'Main' in job titles as that is redundant given
the new subproject name. I replaced that with 'Standard' as the relevant
jobs are tests of standard WF (as opposed to Preview) and aren't the
Bootable jar or Galleon jobs. While I was at it I standardized how we
record in the name the OS and JDK used.
https://ci.wildfly.org/project.html?projectId=WF_MainNightlyJobs&tab=proj...
The initial driver for this was to make it easier to set up nightly jobs
for the micro branches (e.g. 25.x) when we create those branches. We can
just copy this subproject, tweak a few settings and it's done.
We'd already created the jobs for 25.x when I did the job renaming exercise
so those don't have the updated names. Which is fine; they'll likely become
dormant in a couple weeks once we're done with 25.0.1.
Best regards,
--
Brian Stansberry
Project Lead, WildFly
He/Him/His
3 years
