wildfly-maven-plugin execute-command goal on running server instead of embedded?

[Sverker Abrahamsson]

I am running a development setup where I have Wildfly (35.0.1.Final) running in one container and my development environment with maven in another.

I want to run execute-command goal of wildfly-maven-plugin (version 5.1.4.Final) before deploying my build to the server to run various cli scripts to ensure the application server has the correct config.

However, instead of connecting to my running server it appears that the cli scripts are executed on an embedded server and hence fails:

[INFO] --- wildfly:5.1.4.Final:execute-commands (configure) @ sorportal-web ---
[INFO] JBoss Threads version 2.4.0.Final
WARN: can't find jboss-cli.xml. Using default configuration values.
[INFO] JBoss Remoting version 5.0.29.Final
[INFO] XNIO version 3.8.16.Final
[INFO] XNIO NIO Implementation Version 3.8.16.Final
[INFO] ELY00001: WildFly Elytron version 2.6.2.Final
[INFO] Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions.
[INFO] [standalone@embedded /] if ( outcome != success) of /subsystem=messaging-activemq/server=default/jms-queue=vips\/JobbHanteringQueue:read-resource()
[INFO] [standalone@embedded /]     jms-queue add --queue-address=vips/JobbHanteringQueue --entries=[jms/queue/vips/JobbHanteringQueue]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  01:03 min
[INFO] Finished at: 2025-10-01T21:44:33Z
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:5.1.4.Final:execute-commands (configure) on project sorportal-web: Unexpected command '    jms-queue add --queue-address=vips/JobbHanteringQueue --entries=[jms/queue/vips/JobbHanteringQueue]'. Type 'help --commands' for the list of supported commands. -> [Help 1]

If I connect with jboss-cli then I get an prompt like this after connecting to wildfly running in the container appserver:
[standalone@appserver:9990 /]

In the latter case the same cli scripts works with no problems. The issue seems to be related to wildfly-maven-plugin for some reason automatically starts an embedded server. How do I make it connect to the running server instead?

[Sverker Abrahamsson]

The config for wildfly-maven-plugin is as follows, undeploy and deploy works as expected connecting to the running server. Only execute-commands fails:

                    <plugin>

                        <groupId>org.wildfly.plugins</groupId>

                        <artifactId>wildfly-maven-plugin</artifactId>

                        <configuration>

                            <force>true</force>

                            <hostname>appserver</hostname>

                            <username>admin</username>

                            <password>password</password>

                            <protocol>remote+http</protocol>

                        </configuration>

                        <executions>

                            <execution>

                                <id>undeploy</id>

                                <phase>initialize</phase>

                                <goals>

                                    <goal>undeploy</goal>

                                </goals>

                                <configuration>

                                    <match-pattern>sorportal.+\.war</match-pattern>

                                    <match-pattern-strategy>all</match-pattern-strategy>

                                    <ignoreMissingDeployment>true</ignoreMissingDeployment>

                                </configuration>

                            </execution>

                            <execution>

                                <id>configure</id>

                                <phase>initialize</phase>

                                <goals>

                                    <goal>execute-commands</goal>

                                </goals>

                                <configuration>

                                    <autoReload>true</autoReload>

                                    <scripts>

                                        <script>.devcontainer/jboss-init/add-jms.cli</script>

                                        <script>.devcontainer/jboss-init/set-datasources.cli</script>

                                    </scripts>

                                </configuration>

                            </execution>

                            <execution>

                                <id>deploy</id>

                                <phase>install</phase>

                                <goals>

                                    <goal>deploy-only</goal>

                                </goals>

                            </execution>

                        </executions>

                    </plugin>

[Sverker Abrahamsson]

It appears my issue is not related to embedded but that my script uses jms-queue command. The same issue as is described in this post, and the suggested workaround works in my case also:

https://developer.jboss.org/thread/272555

[James Perkins]

Yes, the context for the command is likely not available given this is a remote connection. The command itself just creates an operation and an operation can be executed on a remote server. IMO it's likely best to just use the operation over the high-level command.

[Sverker Abrahamsson]

Other hig-level commands work, and this command work also if I run it in a session with jboss-cli.sh connected remotely to the same server instance.

[James Perkins]

It's likely a context issue. IoW I _think_ jms-queue command requires an additional library be on the class path and it's not there by default. It would work if the server was local because when you set the <jboss-home> in the configuration it uses the CLI artifacts from there. Otherwise, it uses the ones downloaded from Maven and doesn't add the required JMS ones to the class path. The other high level commands are likely part of the core of CLI.