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/
10 months, 2 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
11 months, 2 weeks
Planned removal of Weld Probe
by Matej Novotny
Hello
This email is to let users and the community know that we are considering
removing development mode, known as Weld Probe, from the next version of
Weld 5.
Tracking issue for this can be seen here[1] but I will provide a short
overview for this decision below. We value feedback so please don't
hesitate to reach back via this email, JIRA issue or via Gitter.
First of all, the reason why we want to remove it is because the tool has
been left unmaintained for an extended period of time. Namely the UI part
is fairly outdated; especially the libraries it uses. We lack the time
and/or manpower to completely rewrite and maintain the client part of Probe
(the single page html UI) which is why we opted for removal rather than
shipping outdated code.
There are two ways we can go about this:
1. Complete removal of Probe with all of its parts
- this means there will be no development mode and it removes all Probe
code
- removes (or deprecates) any configuration options linked to it
2. Removal of just the client side code (the UI) and keeping Probe
internals which expose all the information via JSON
- this would only remove UI parts of Probe; you'd no longer get any means
to inspect the deployment except JSON data
- however, this allows for custom community client to be written and to
consume this data
As we lack any data on whether Probe is being currently used and whether
the community would appreciate keeping the JSON data, we are at the moment
leaning towards removing Probe altogether.
That being said, if there is interest from the community, we'd be more than
happy to keep the JSON parts of Probe in place so don't hesitate to reach
out and tell us. Last but not least, even if Probe gets removed now, we can
reintroduce it at a later point in time.
Regards
Matej
___________________________________________________________
[1] https://issues.redhat.com/browse/WELD-2733
11 months, 4 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
1 year
