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
4 years, 9 months
Native jakarta.* artifacts in WildFly Preview
by Brian Stansberry
Overview
We've done a lot of good work on WildFly Preview in the last year but as
planning work in Jakarta on EE 10 starts to get underway I hope we can make
a lot more progress, specifically in increasing the number of 'native'
jakarta.* EE 9.1 components' we use. This will allow us to focus on EE 10
dev when the time comes. Ideally by the time WF 26 comes out in the Dec/Jan
timeframe we'll have eliminated the transformation of artifacts that we do
when provisioning a server with the wildfly-preview feature pack, and
instead we'll be using native jakarta artifacts available in maven central
or repository.jboss.org.
This thread is meant to drive discussion about how to do this. WF devs of
course don't control many projects that provide components, so for those
this discussion would be more informational for the WF subsystem leads who
interact with those communities.
By a 'native jakarta component' I mean one whose compiled artifacts use the
jakarta namespace and otherwise support EE 9.1.
If at all possible it should also provide a matching -sources jar, to help
provide a better debugging experience. This is particularly important for
components against which WildFly users would compile applications.
For artifacts we package in modules that we don't mark with
jboss-api="private" or jboss-api="unsupported", it should also provide a
matching -javadoc jar.
Priority
More urgent are components against which other WF components compile, where
EE classes are part of the API compiled against. The closer a component is
to the root of a dependency chain, the higher the priority, as having a
native component makes it easier for other components to do their work.
EE API spec forks are not necessarily urgent unless WF itself intends to
use that fork instead of the Eclipse project. (We need to formally resolve
which EE 9+ spec forks WF needs, which is a separate topic. WF Preview is
currently using fewer spec forks than standard WF.)
Approaches
There are a number of approaches a project can follow to produce native
components, each with pros and cons
1) Branching and updating code.
This obviously works, but it comes with a big cost if there will be
continued demand for updates using the javax.* namespace. IMHO it is pretty
likely that there will be continued demand for many components to provide
updates to their javax.* releases.
I had been thinking that during the WF 26 cycle WF itself might follow this
approach, but I'm increasingly thinking we should follow one of the other
approaches.
An issue with this is it means you are compiling, which means you need
jakarta.* components to compile against, which may not be available. If
not you can try Stuart Douglas's optimus project to generate during your
build transformed deps to build against. James Perkins tells me he is
working on something along these lines to add to wildfy-extras/batavia.
2) Adapters
Some components might be able to support both javax and jakarta in the same
code base abstracting away the EE API and providing adapters. Not much to
say about this; you know better if it fits your component.
3) Bytecode transformation with a maven qualifier
Here you update your pom and add a plugin execution that transforms that
maven module's normal javax binary to produce another artifact with a
different qualifier.
The key downside to this is it doesn't produce matching -sources.jar or
-javadoc.jar artifacts. So I don't think it should be our preferred
approach.
Jackson 2.12 did this for a few artifacts, e.g.
https://github.com/FasterXML/jackson-jaxrs-providers/blob/2.12/json/pom.x...
They used the shade plugin. This can also be done using
wildfly-extras/batavia or Eclipse Transfomer directly.
4) New maven module, transform all artifacts
Create a new maven module to pair with your javax-based module. Add
"-jakarta" to the artifactId. Module just has a pom. Pom uses plugins that
call the Eclipse Transformer to transform *all* the artifacts from module
it is paired with (binary jar, -sources.jar, -javadoc.jar)
Narayana did this -- see https://github.com/jbosstm/narayana/pull/1824/files
Hibernate does this for its 5.5 series. This is a gradle build.
https://github.com/hibernate/hibernate-orm/blob/main/hibernate-core-jakar...
5) New maven module, transform source and build
Create a new maven module to pair with your javax-based module. Add
"-jakarta" to the artifactId. Module just has a pom. Use the Eclipse
Transformer to transform the unzipped source from the javax module, writing
it to generated-sources in the jakarta.* module. Then build the jakarta.*
artifacts from the generated source.
Examples of this:
https://github.com/wildfly/wildfly/pull/14485
https://github.com/jboss/metadata/pull/142
A pro (and con) of this approach is you can also transform src/test and
then run the tests. (A con because it can send you down rabbit holes
getting tests to work. That can reveal things that are good to know though.)
Another con is again this means you are *compiling* which means you may
need jakarta.* deps to compile against.
6) Don't transform
There may be some components that use EE APIs internally but objects don't
leak in or out. A possible example would be JSON where a component might
want to deal with JSON for completely internal purposes, and used EE JSON
for convenience. In theory WF could provide javax JSON via internal modules
and the components using it could skip transformation.
I did a similar thing with H2, which provides some servlet integration
classes that WF does not support. I see no reason to worry about a native
jakarta.servlet H2 so I sent up a PR to disable transformation of it:
https://github.com/wildfly/wildfly/pull/14313
Lots to digest here; discussion is very much welcome.
Best regards,
Brian
5 years, 1 month
OpenTelemetry Support
by Jason Lee
Good afternoon! In case you missed my announcement, we've been working on
adding OpenTelemetry support to WildFly. I currently have an implementation
that works, for some value of "works", so what we could really use now is
your feedback.
If you have any interest in the topic, please take a look at my blog entry
for details, then provide feedback via your channel of choice.
https://jasondl.ee/posts/2021/an-update-on-opentelemetry-and-wildfly.html
Any and all feedback is welcome, from how the library is exposed to
applications to how the library is configured in the server, and anything
in between.
No timeline for shipping has been set just yet, so now's your chance to
make your voice heard before the feature ships.
Thanks!
Jason Lee
Principal Software Engineer
Red Hat JBoss EAP
5 years, 1 month
PicketBox Vault Removal
by Darran Lofthouse
For a while we have been talking about the upcoming removal of legacy
security after WildFly Elytron was introduced in WildFly 11.
The time has now come to commence the removals, the first area being
handled is the removal of the PicketBox vault integration.
More information is available in the following analysis proposal:
https://github.com/wildfly/wildfly-proposals/pull/405
Regards,
Darran Lofthouse.
5 years, 1 month
WildFly Preview and module.xml files
by Brian Stansberry
tl;dr; Let's figure out how to avoid duplicating module.xml files
in the WildFly Preview code.
Long version
One of the things we're trying to do with WildFly Preview is to make the
code differences vs standard WildFly as minimal as possible. There are some
things that have to differ, like some Galleon feature-group or layer
definitions (because WFP has different standard config files), plus the pom
dependency stuff because WFP uses some native EE 9.1 artifacts. But beyond
that the less code the better, particularly any duplicated code.
One area where we've been creating a lot of duplicated code is various
module.xml files. You don't need to fork a module.xml into the
ee-9/feature-pack src tree if all you want to do is use a different version
of an artifact. But for any other change, we've been forking. That's
increasingly problematic as any forked module.xml is a bug waiting to
happen. And we're starting to get more of them.
Most, probably all, module.xml forks are because the WFP module uses an
artifact with a different GAV or maven classifier. The dependency set is
the same.* So how can we avoid forking the module.xml?
One possibility is to use maven-resource-plugin filtering to control the
module.xml artifact name attribute. This is actually pretty
straightforward -- a POC is here:
https://github.com/wildfly/wildfly/pull/14507
I wouldn't want to get too carried away with that, e.g. replacing totally
different GAVs. But for things where a project is releasing javax and
jakarta artifacts at the same time with slightly different artifact ids or
using a qualifier, it seems reasonable.
WDYT?
* Note that there is no need at this point to fork a module.xml because it
has a dependency on some javax.xxx.api module (for the EE API) and you want
to change it to jakarta.*. In WFP we provide javax.xxx.api modules but
they are all aliases to the corresponding jakarta.xxx.api module. This
means a module.xml with an EE API dep will work unchanged. Others may
disagree, but I think at this stage it's best to use the javax.* modules
for all deps, even in WFP. It just seems cleaner to do things one way vs
having a mix. But I totally admit that's a personal preference.
Best regards,
Brian
5 years, 1 month
