9:10 a.m.
Hi,
an heads-up that we are changing the approach when provisioning WildFly
with Galleon layers in the WildFly testsuite.
Prior to https://github.com/wildfly/wildfly/pull/17153 (that should be
merged soon), a base layer (e.g.: cloud-server) + some decorator layers
(according to the test case) were explicitly set to provision servers
used by tests. So the actual set of required Galleon layers was
generally larger than what the test actually requires.
Thanks to the WildFly Glow <https://github.com/wildfly/wildfly-glow>
Arquillian Maven plugin, we are now scanning the Arquillian deployments
(prior to the test execution) to discover the required Galleon layers. A
provisioning.xml file containing the discovered layers is generated and
used by the WildFly Maven plugin to actually provision the test server.
In order to validate that what the scanning has discovered is expected,
you can configure the wildfly-glow-arquillian-plugin maven plugin to
contain the element <expected-discovery>. For example:
<expected-discovery>[cdi, ee-integration, ejb, ejb-lite,
elytron-oidc-client, naming,
servlet]==>ee-core-profile-server,ejb,elytron-oidc-client</expected-discovery>
The left part of the arrow contains the list of the discovered layers
according to the scanning. The right part is what will get provisioned.
Composed of a base layer (always ee-core-profile-server) + a list of the
discovered layers that has been cleaned-up to avoid to include dependencies.
BTW: The PR https://github.com/wildfly/wildfly/pull/17153 contains a lot
of examples of WildFly Glow scanning executions that you can use as
starting-point.
In case the test depends on some not discoverable features, you have the
ability to explicitly add add-ons to enrich the set of provisioned
layers (using the <add-ons> configuration element).
In addition, it can happen that some errors are identified by WildFly
Glow. Some need to be fixed, some could be fine in the context of the
tests. Errors that are fine in the context of the test can be ignored
using the <expected-errors> element.
Known WildFly Glow discovered errors:
* jakarta.naming.Context or InitialContext lookup: In case some lookup
is present in the test code that could hide the usage of a layer not
discovered. You can configure the plugin with <add-layers-for-jndi> to
add the layers that are required (if any) and hidden.
* ambiguous resource injection: An un-typed resource injection could
hide a required layer. You can configure the plugin with
<add-layers-for-jndi> to list the layers that are required (if any) and
hidden.
* an add-on of the messaging family is expected by the
messaging-activemq layer. One of embedded or remoting messaging add-on
is required.
* unbound datasources error: <name of ds>: A datasource is expected but
not found in the deployment. That is generally an error to ignore, the
test itself should add the datasource during the setup.
* no default datasource found error: It has been identified that a
default datasource is required. That can be fixed by adding the add-on
h2-database:default
You can find more information related to WildFly Glow in its
documentation <http://docs.wildfly.org/wildfly-glow/>;.
Thank-you.
JF