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 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.

Thank-you.

JF

_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
Privacy Statement: https://www.redhat.com/en/about/privacy-policy
List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message/6YJ4ZNAYYHDKZLCDPJJ2RJMCB3RARSUU/