Commands not executed as expected

[hantsy]

I tried to execute some custom commands when running wildfly:run, my stack is:

• Java 17
• Wildfly Preview 27.0.0.Alpha5
• WildFly maven plugin 4.0.0.Beta3

<properties>
      <!-- Wildfly server -->
      <wildfly.artifactId>wildfly-preview-dist</wildfly.artifactId>
      <wildfly.version>27.0.0.Alpha5</wildfly.version>
      <wildfly-maven-plugin.version>4.0.0.Beta3</wildfly-maven-plugin.version>
      <jboss-as.home>${project.build.directory}/wildfly-preview-${wildfly.version}</jboss-as.home>
  </properties>
  <build>
      <plugins>

          <!-- unpack a copy of WildFly-->
          <plugin>
              <groupId>org.apache.maven.plugins</groupId>
              <artifactId>maven-dependency-plugin</artifactId>
              <version>${maven-dependency-plugin.version}</version>
              <executions>
                  <execution>
                      <id>unpack</id>
                      <phase>process-classes</phase>
                      <goals>
                          <goal>unpack</goal>
                      </goals>
                      <configuration>
                          <artifactItems>
                              <artifactItem>
                                  <groupId>org.wildfly</groupId>
                                  <artifactId>${wildfly.artifactId}</artifactId>
                                  <version>${wildfly.version}</version>
                                  <type>zip</type>
                                  <overWrite>false</overWrite>
                                  <outputDirectory>${project.build.directory}</outputDirectory>
                              </artifactItem>
                          </artifactItems>
                      </configuration>
                  </execution>
              </executions>
          </plugin>
          <plugin>
              <groupId>org.wildfly.plugins</groupId>
              <artifactId>wildfly-maven-plugin</artifactId>
              <version>${wildfly-maven-plugin.version}</version>
              <configuration>
                  <!-- <scripts>
                      <script>config.cli</script>
                  </scripts> -->
                  <commands>
                      <command>/subsystem=undertow/application-security-domain=other:write-attribute(name=integrated-jaspi, value=false)</command>
                      <command>:reload</command>
                  </commands>
              </configuration>
          </plugin>
      </plugins>
  </build>

From the wildfly:run doc, the commands should be executed before deployment. But I encountered the following exceptions when running mvn clean package wildfly:run -Pwildfly.

18:49:27,522 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0018: Host default-host starting
[INFO] Finished at: 2022-09-16T18:49:27+08:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:4.0.0.Beta3:run (run) on project security-oidc-examples: The server failed to start: java.io.IOException: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: Connection refused: no further information -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
18:49:27,824 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
18:49:27,825 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0006: Undertow HTTPS listener https listening on 127.0.0.1:8443
18:49:27,826 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0493: Jakarta Enterprise Beans subsystem suspension complete
18:49:27,827 INFO  [org.jboss.ws.common.management] (MSC service thread 1-7) JBWS022052: Starting JBossWS 6.0.0.Final (Apache CXF 3.5.2.jbossorg-3)
18:49:27,828 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
18:49:27,907 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
18:49:27,908 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Preview 27.0.0.Alpha5 (WildFly Core 19.0.0.Beta15) started in 1040ms - Started 290 of 563 services (357 services are lazy, passive or on-demand) - Server configuration file in use: standalone.xml
18:49:27,911 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
18:49:27,911 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990

It seems the management is not ready when executing commands.

I also tried to use scripts/script and an external config.cli file, got the same result.

# config.cli
batch
# set integrated-jaspi to false
/subsystem=undertow/application-security-domain=other:write-attribute(name=integrated-jaspi, value=false)

# Execute and reload
run-batch
:reload

The example project is https://github.com/hantsy/jakartaee10-sandbox/tree/master/security-oidc, use the commands to disable the intergrated-jaspi to make the oidc works. I go the solution from https://blogs.nologin.es/rickyepoderi/index.php?/archives/198-Using-jakartaee-10-security-OIDC-with-wildfly-27-preview.html but I would like use a command lien to automate all things.

[jfdenise]

@hantsy , the problem is caused by the :reload command that doesn't block. So the deployment is operated against a reloading server and fails.
Please use the reload command, not the :reload

[hantsy]

The content of the config.cli file is modified from the docs of Wildfly Maven plugin, so I think :reload should work.

[jamezp]

The difference is :reload is an operation denoted by the :. On the other hand reload is a command withing CLI. The operation returns immediately where as the command returns after the container has been restarted. There is nothing the plugin can do to resolve that without some hacks which IMO should not be done since reload should solve the issue.