Better synergies for WildFly Container images
by Jean-Frederic Mesnil
Hi,
To run WildFly on a Cloud with a container image, you have 2 approaches:
* Use the “docker” image that provides a downloaded installation of WildFly, put your deployment in it and deploy on your container platform.
* Use the “s2i” images to build an application with S2I (Source-to-image) on OpenShift, put it in a runtime image and deploy it on OpenShift.
Both approaches have their own strength and weaknesses and evolved at their own pace without any coordination.
However in the last few months, the activity on the docker image slowed down due to external factor (hub.docker constraints) and our lack of attention to it…
Meanwhile, we have ramped up the activity on the S2I images and provided a whole new architecture that relies on Maven to assemble the application runtime (WildFly + deployments) instead of hiding that assembly in the S2I process.
I just wrote down an article on wildfly.org explaining how WildFly users that uses the “docker” image can adapt their workflow to the new architecture (without having to switch to S2I!)
https://www.wildfly.org/news/2022/08/04/wildfly-maven-docker/
The target audience for this article is the “docker” users so that they can keep their workflow (I build my deployment, I create a container image from a Dockerfile) and benefit from all the work done around WildFly provisioning (feature packs, layers, packaging scripts, etc.)
While writing this article and looking at the issues for the docker image, I spotted a few themes shared between all these images:
* We want to consume more recent versions of JDK (17 in particular)
* We want to run on linux/arm64 (in addition to Intel arch)
* We want to trim the image size / reduce the surface area of security attacks
* We want better image health index
I think the investment we made on the S2I bundler and runtime images can benefit to the docker image and vice versa.
In particular, we are dedicated to provide a runtime image that contains all it needs to run WildFly (ie OpenJDK + a few more bits) with a good health index.
On the docker image, the base-jdk image we are using is lagging behind and I wonder if we should not take the opportunity to use the WildFly runtime image as the base for the docker image (after all, its sole purpose is to run WildFly!)
I’ve started a Board to list the synergies and feature gap we have in our images:
https://trello.com/b/QGnEci3i/willdfly-image-alignments
I think that using the runtime image as the base image for the docker image would be an enabler for a lot of this work and would ensure that WildFly is in better shape to run on containers.
As I wrote in the article, we will continue to deliver the Docker image for WildFly but we are focusing on the new architecture and the new images to expand the capabilities of WildFly.
We are looking forward to our users trying this new approach and validates how it improves their workflow.
I’ve opened this thread to gather input on this alignment to make sure we get all the requirement in place before putting this in action.
I’m looking forward to hearing your ideas on it.
Best regards,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
4 months, 3 weeks
Schedule for WildFly 27 Beta1 and Final
by Brian Stansberry
As we wrap up our work on WildFly 26.1.2 and on our EE 10 compliance for
WildFly 27, I've been having some discussions re target dates for WildFly
27 Beta1 and Final.
The following is what we're looking at:
27.0.0.Beta1:
WF Core feature freeze -- Friday Sep 9
WF feature freeze -- Monday Sep 12
Tag and release -- Wednesday Sep 14 / Thur Sep 15
27.0.0.Final:
WF Core feature freeze -- Friday Sep 23
WF feature freeze -- Monday Sep 26
Tag and release -- Wednesday Sep 28 / Thur Sep 29
Beta1 will be like all WF betas in recent years -- feature complete and
using .Final production code dependencies except for WF Core and _perhaps_
one or two other components where we know we can produce and integrate a
.Final within a day.
Note that I expect we'll do a 27.0.0.Alpha5 at some point between now and
Beta1. That will be like the other alphas for 27; just a deploy to JBoss
Nexus and addition of the zip/tars to the downloads page. We'll do this to
support our EE 10 compatibility certifaction requests.
Best regards,
--
Brian Stansberry
Project Lead, WildFly
He/Him/His
5 months, 3 weeks
Jandex 2.4.3 and the path to 3.0
by Ladislav Thon
Hi,
last week, I've released Jandex 3.0.0-RC1, and yesterday, I've released
Jandex 2.4.3.Final. (A corresponding release of the Jandex Maven plugin is
on its way to Central as we speak.)
There's a few breaking changes in Jandex 3.0 and the 2.4.3 release is
supposed to make migration easier (or at least require less coordination).
Specifically, Jandex 2.4.3 deprecates these 2 methods because they have a
different return type in 3.0:
- ClassInfo.annotations()
- MethodInfo.parameters()
Replacements are, respectively:
- ClassInfo.annotationsMap()
- MethodInfo.parameterTypes()
These 2 replacement methods are present both in Jandex 2.4.3 and
3.0.0[-RC1].
Additionally, certain usages of MethodInfo.parameters() can be simplified
using MethodInfo.parametersCount() and parameterType(int). These 2 methods
are also present both in 2.4.3 and 3.0.0[-RC1].
Updating to Jandex 2.4.3 is safe, because it's fully compatible with
previous releases. A project that uses Jandex 2.4.3 and avoids deprecated
methods is almost fully _binary_ compatible with Jandex 3.0 (almost because
of the return type change in Indexer.index(), but that should only affect a
very small number of existing code paths).
I went through the projects that I know use Jandex and made the necessary
changes myself and will submit PRs in the coming days. These projects are:
- Quarkus, including ArC and RESTEasy Reactive
- Gizmo
- Weld
- SmallRye OpenAPI
- SmallRye Async API -- no changes required
- SmallRye GraphQL
- WildFly Core -- no changes required, just updating Jandex
- WildFly Full
- RESTEasy (classic) -- no changes required
If you maintain (or know about) some other project that uses Jandex, feel
free to ping me, I'll be happy to help.
Note that there are more changes in Jandex 3.0. All the details can be
found in the issue tracker: https://github.com/smallrye/jandex/milestone/3
For your convenience, here's a summary of what's coming in Jandex 3.0 and
is technically a breaking change, even though most of them won't likely
affect anyone:
- moved Jandex to SmallRye
- bumped minimum Java version to 8
- regularized access to annotations from AnnotationTarget
- this is why ClassInfo.annotations() needs to change the return type
- there are methods to access annotations without considering nested
annotation targets, too!
- regularized access to method parameters from MethodInfo
- this is why MethodInfo.parameters() needs to change the return type
- common parameter-accessing methods on MethodInfo ignore
mandated/synthetic parameters
- special methods exist to access all parameters, including
mandated/synthetic
- added a new kind of types, TypeVariableReference, to faithfully represent
recursive type variables
- changed Indexer.index() to return void (instead of ClassInfo)
- required to be able to post-process an index during Indexer.complete()
- added indexing of class-retained annotations
- Jandex 2 only indexes runtime-retained annotations
- AnnotationInstance.runtimeVisible() can be used to distinguish
- added a few methods to IndexView
- navigation for interfaces: getKnownDirectSubinterfaces(),
getAllKnownSubinterfaces()
- navigation for packages: getClassesInPackage(), getSubpackages()
- breaks projects that implement this interface on their own (which I
know at least WildFly and Quarkus do)
- removed IndexReader.getDataVersion()
- it's been incorrect anyway, and I couldn't find anyone using it
When Jandex 3.0 goes final, which I hope happens in a few weeks, I will
publish an announcement with all details on the SmallRye blog. In the
meantime, I'll use the previously mentioned projects (and their test
suites) to verify that Jandex 3.0 doesn't contain any hidden surprises.
Any questions? Ideas? My inbox and the Jandex issue tracker are always open
:-)
Thanks,
LT
6 months, 1 week
Re: Schedule for WildFly 26.1.2
by Ben Langley
Hi,
I have a customer that will need R26.1.2, they will very likely need to
stay on this version for sometime. Your community post
<https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...>regarding
26.1.2 suggests this version should have been available for download
25/08/2022 but I don't see it on the downloads yet?
Please could you confirm if this version will still be released and if so
when?
Thanks
Ben
*Ben Langley*
*Project Manager*
*Public Safety*
Upcoming Leave 01/08 to 12/08
*M*: 07805913576
*E*: ben.langley(a)necsws.com <tony.newland(a)necsws.com>
*W*: www.necsws.com
NEC Software Solutions
Minster Corner
South Church Side
Hull
East Yorkshire
HU1 1RR
--
This email is sent on behalf of NEC Software Solutions UK Limited and its
associated companies (together "NEC Software Solutions") and is strictly
confidential and intended solely for the addressee(s). Full details of
those companies can be found at
https://www.necsws.com/group-company-details/
<https://www.necsws.com/group-company-details/>
If you are not the intended
recipient of this email you must: (i) not disclose, copy or distribute its
contents to any other person nor use its contents in any way or you may be
acting unlawfully; (ii) contact NEC Software Solutions immediately on
+44(0)1442 768445 quoting the name of the sender and the addressee then
delete it from your system.
NEC Software Solutions has taken reasonable
precautions to ensure that no viruses are contained in this email, but does
not accept any responsibility once this email has been transmitted. You
should scan attachments (if any) for viruses.
6 months, 1 week
Proposal to drop source transformation for wildfly-client-all submodule
by Cheng Fang
The current WildFly project contains both wildfly-client-all submodule (client/shade), and wildfly-client-all-jakarta (ee-9/source-transform/client/shade). Now that WildFly has migrated to Jakarta EE 10, we should migrate the submodule itself and remove the module from the source transformer.
In WFLY-16881 <https://issues.redhat.com/browse/WFLY-16881>, I plan to drop this source transformation submodule, and make the standard wildfly-client-all module to support Jakarta EE 10 API.
So after dropping the source transformation, there will be no artifact named wildfly-client-all-jakarta produced from WildFly build. Instead, wildfly-client-all submodule will produce wildfly-client-all artifact that supports Jakarta EE 10 API and related artifacts.
If you know of any components or projects rely on a wildfly-client-all-jakarta artifact, or a legacy wildfly-client-all artifact from current WildFly build, please discuss here.
Thanks,
Cheng
7 months, 1 week
