WildFly Calendary Proposal
by Jason Lee
I have a PR open that is a first step in creating a calendar of
WildFly-related events: https://github.com/wildfly/wildfly.org/pull/439
Brian does a great job of emailing the WF dev schedule to this list, but,
for me, it tends to get buried and lost. What I'd love to be able to do is
subscribe to a .ics and have events show up on my calendar. This is a step
toward that. What would be nice is to take that one step further and make
it available in a human-friendly form on wildfly.org as well.
All that said, I would love feedback on the idea itself, the contents of
the calendar, etc. to see if this would be useful to more than just myself.
Additionally, I know we have various community efforts going on at the
moment, so if this overlaps with any of that, I'm happy to roll this into
those efforts.
Jason Lee
Principal Software Engineer
Red Hat JBoss EAP
1 year
WildFly Glow project status
by Jean Francois Denise
Hi WildFly community,
We would like to advertise the existence of the WildFly Glow
<https://github.com/wildfly/wildfly-glow>project.
WildFly Glow is an evolution of the WildFly Galleon
<https://docs.wildfly.org/galleon/>provisioning tooling.
It is currently an Alpha, and getting feedback from the community at
this point would be very valuable!
The goal of this project is to offer some tooling to identify the set of
Galleon feature-packs and layers that are required by your application.
The entry-point of this discovery being the application deployment.
Automatic identification of WildFly Galleon layers
Today, in order to trim a WildFly server to fit the application
requirements, you have to first identify the set of WildFly Galleon
layers
<https://docs.wildfly.org/30/Galleon_Guide.html#wildfly_galleon_layers>to
use.
WildFly Glow identifies the layers for you by scanning your application
war (jar or ear) files.
This application to Galleon layers mapping is based on rules contained
in WildFly Galleon layers (starting WildFly 29).
These rules express the Java types, annotations and files (XML
descriptors, properties files, ...)
that are bound to the usage of a given Galleon layer. An example of
rules can be found in the jaxrs
<https://github.com/wildfly/wildfly/blob/main/ee-feature-pack/galleon-shar...>layer.
In this example we look for REST API usage and a servlet class located
in a web.xml file.
Once the layers are identified, the Galleon feature-packs that define
them are selected and included.
Centralized knowledge of WildFly Galleon feature-packs
You can today extend a WildFly server at provisioning time by the means
of extra Galleon feature-packs. For example, some feature-packs exist to
connect to databases, to enable a gRPC endpoint, to enable the Keycloak
SAML protocol, to replace the JSF implementation with myFaces, to
integrate resteasy-spring features into WildFly, etc (non exhaustive list).
WildFly Glow has, per WildFly version, the knowledge of compatible
Galleon feature-packs. It offers a centralized view on extra features
you can add to your WildFly server.
Going beyond discovered Galleon layers
WildFly Glow does more than identifying Galleon feature-packs and layers.
Provisioning
WildFly Glow tooling allows you to provision a WildFly server or a
WildFly Bootable JAR or produce a Docker image.
WildFly additional features discovery
Not all WildFly server features can be discovered by scanning your
application deployment. A good example is the usage of SSL to secure the
http server access. Another one is the need for WildFly tooling (e.g.
WildFly CLI, elytron tooling, ...).
WildFly Glow allows you to include, according to what has been
discovered in the deployment, a set of additional WildFly features
called `add-ons` that makes sense for your application. Implementation
wise, such add-ons are Galleon layers. For example, the SSL add-on is
implemented by the undertow-https
<https://github.com/wildfly/wildfly/blob/main/ee-feature-pack/galleon-shar...>layer.
Connection to databases
WildFly Glow detects that your application requires a datasource and
will suggest you with database `add-ons` to be included in order to
connect to the DB of your choice (postgresql, mysql, ...). The
Datasources feature-pack layers implement these add-ons. For example,
the postgresql
<https://github.com/wildfly-extras/wildfly-datasources-galleon-pack/blob/m...>add-on.
High Availability profile handling
Currently, to provision an HA WildFly server using galleon layers, you
need to exclude the non HA Galleon layers and include their HA
counterparts (e.g.: ‘jpa-distributed
<https://github.com/wildfly/wildfly/blob/main/ee-feature-pack/galleon-shar...>’
layer used instead of the ‘jpa’
<https://github.com/wildfly/wildfly/blob/main/ee-feature-pack/galleon-shar...>layer,
‘ejb-dist-cache
<https://github.com/wildfly/wildfly/blob/main/ee-feature-pack/galleon-shar...>’
instead of the ‘ejb-local-cache
<https://github.com/wildfly/wildfly/blob/main/ee-feature-pack/galleon-shar...>’).
When the HA profile is enabled, WildFly Glow handles the correct
inclusions and exclusions of layers.
WildFly Glow tooling
WildFly Glow offers currently 2 main usages:
* A Command Line interface (`wildfly-glow` CLI) that scans your
deployment and can provision a WildFly server, a WildFly Bootable JAR and
a Docker image (to be deployed on Kubernetes). From the CLI you can
discover the list of available `add-ons` and enable them. WildFly Glow
currently supports Wildfly 29 and 30. The latest WildFly major
(currently 30.0.0.Final) is the default when no WildFly version is
specified.
* An integration with the WildFly Maven plugin (Starting 5.0.0.Alpha2)
`package` goal, to provision a WildFly server without specifying
feature-packs and layers.
Current status
We are currently at an Alpha level and working to reach a Beta level of
quality. We have a draft PR
<https://github.com/wildfly/wildfly/pull/17153>that updates the WildFly
integration testsuite to use the WildFly Glow arquillian Maven plugin
(that scans arquillian test deployments) instead of relying on hard
coded Galleon layers. 100% of the tests that use Galleon provisioning
have been updated.
We plan to put in place a WildFly quickstarts
<https://github.com/wildfly/quickstart>preview branch that updates all
quickstarts to rely on WildFly Glow.
We also plan to integrate more feature-packs inside the WildFly Galleon
feature-packs
registry
<https://github.com/wildfly/wildfly-galleon-feature-packs/tree/release>.
Some candidates for which we have Proof of Concept integrations are:
keycloak
<https://github.com/jfdenise/keycloak/tree/layers_metadata_final>,
myfaces
<https://github.com/wildfly-extras/wildfly-myfaces-feature-pack>,
graphql
<https://github.com/jfdenise/wildfly-graphql-feature-pack/tree/layers_meta...>,
resteasy-spring
<https://github.com/jfdenise/resteasy-spring/tree/galleon-layer>.
BTW: if you are defining Galleon feature-packs for WildFly that would be
helpful for the community, we should get in touch.
A good way to get started with WildFly Glow is by downloading the latest
CLI (1.0.0.Alpha7) from here
<https://github.com/wildfly/wildfly-glow/releases>and scan your deployments.
Feel free to provide us with your feedback!
Thank-you.
JF Denise
2 years, 3 months
Github Actions are not free
by Brian Stansberry
Before anyone adds any more github actions to projects in the 'wildfly'
github org, please discuss here or in zulip.
GH actions jobs have been essentially free for a long time from our naive
POV, but we do have a max of 20 concurrent jobs across the whole github
org, which we're starting to hit
So we should discuss new ones to make sure they are a good use of our limit.
Best regards,
Brian
2 years, 3 months
