Local redeployment

[Sebl29]

yesterday I got very bored by restarting my Application Server (WildFly) every time when I assemble my EAR and using cargoStartLocal/cargoRunLocal, because WildFly is able to redeploy it on runtime.

Primary Issue:

So what I am missing, is a task cargoRedeployLocal on a running instance. For convenience I would also suggest a task cargoDeployLocal, which dependsOn cargoStartLocal, if not yet started. So this local tasks are my primary issue.

Workaround 1 (without success):

The suggestion in #102 of using cargo*Local for start/stop and redeploy with cargoRedeployRemote did not work for me. Perhaps we could make this work. Here is my config for cargo:

cargo {
    containerId = 'wildfly8x'
    deployable {
        file = file('myApplication.ear')
    }
    ...
    remote {
        hostname = 'localhost'
        // this should correspond to the user in /config/wildfly/mgmt-users.properties, your local wildfly admin.
        username = 'admin'
        password = 'admin'

        // containerProperties {
        //     property 'cargo.jboss.management-http.port', 8787 // default: 9990
        // }
        // containerProperties {
        //     property 'cargo.protocol', "http" // ?!? does not make any difference on cargoRedeployRemote!
        // }
        // containerProperties {
        //     property 'cargo.timeout', "60000" // ?!? does not make any difference on cargoRedeployRemote!
        // }
    }
    local {
        ...
        jvmArgs = '-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n'
        installer {
            installUrl = 'http://download.jboss.org/wildfly/8.2.0.Final/wildfly-8.2.0.Final.tar.gz'
            downloadDir = file("$wildfly/download")
            extractDir = file("$wildfly")
        }
        ...
    }
}

With gradle cargoRedeployRemote --stacktrace this results in:

...
Caused by: java.net.ConnectException: JBAS012144: Could not connect to remote://localhost:9990. The connection timed out
    at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:130)

In my standalone.xml this port 9990 is defined here:

<server>
    ...
    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
        ...
        </socket-binding-group>
</server>

In the WildFly Console (the browser-GUI) you can also check under Configuration-->Socket Binding that "management-http" is an available socket. So, perhaps I have to define another port instead of "management-http" or something. Any help would be appreciated.

Workaround 2:

My current workaround is a gradle copy task:

task redeploy (type: Copy) {
    from file("myApplication.ear")
    into System.properties['user.home'] + "\\AppData\\Local\\Temp\\cargo\\conf\\deployments"
}

On file base you can see that WildFly will recognize the new *.ear and start deploying (creating files "myApplication.ear.isdeploying" and "myApplication.ear.deployed").
But IMHO this should be part of the gradle-cargo-plugin, because the locations (from, into) are already known by the plugin.

[bmuschko]

You'd have to request these things from the Cargo project. My plugin only passes the calls to the Cargo Ant tasks.

[Sebl29]

Hi bmuschko,
as I read the cargo ant documentation http://cargo.codehaus.org/Ant+support , the "deploy" and "redeploy" action do this ("Deploy a deployable to a running container." and "Undeploy and deploy again a deployable. If the deployable was not deployed before calling redeploy, it will simply be deployed."). So cargo already supports this, doesn't it? So the gradle plugin only needs two or four similar tasks. Correct?

btw: nice plugin, it makes our setup with gradle much simpler!

[bmuschko]

The actions you mention are already part of the tasks provided by the plugin: cargoDeployRemote, cargoUndeployRemote, cargoRedeployRemote. You want to use the against a local, already running instance you'll need to configure the plugin to work against localhost. It seems like you already tried to do that. If that hasn't worked so far, it must be an issue with your Wildfly configuration. Unfortunately, I never used Wildfly before so I don't have an idea what could be wrong.

BTW: You cannot combine the local tasks with the remote tasks of the plugin. They severe distinct use cases and also work differently under the covers on the Cargo side. You might also want to watch this video. It might help understanding some of the use cases.

[Sebl29]

yes, I mixed up cargo_Local and cargo_Remote task, because I want to make use of the installer, which is only available with the local setup. That's the reason, why I am missing such cargo(Re)DeployLocal tasks, which should be available on the ant-side.
Any chance for me, to use the local installer and (re)deploy?

Nice video, I will definitely have a look at it (but not enjoying 44min youtube in the office ;-)).

[bmuschko]

I don't think it's possible. The actions deploy, undeploy and redeploy are listed under "Remote deployment".