Cargo hangs while starting GlassFish 4.x and uses up 100% CPU

Question

Trying to go with Maven Cargo plugin instead of the Maven GlassFish plugin that doesn't support hot redeploy. Cargo hangs on goals start/run for GlassFish local existing installation and eats up to 100% CPU until I kill it! I tried with a plain text password and then created a password file, same result. Online searching turns up posts with various kinds of Cargo-GlassFish configuration, almost all of them older than the versions I'm using, and didn't help either. Maven plugin config and debug log are attached. Any help is appreciated.

Environment: Mac OS X Mavericks, Oracle JDK 1.7.0_45, GlassFish-4.0-b89, Maven 3.1.1, cargo-maven2-plugin 1.4.5

Maven plugin config

<plugin>
  <groupId>org.codehaus.cargo</groupId>
  <artifactId>cargo-maven2-plugin</artifactId>
  <version>1.4.5</version>
  <configuration>
    <container>
      <containerId>glassfish4x</containerId>
      <type>installed</type>
      <output>${glassfish.installDirectory}/glassfish/domains/${glassfish.domainName}/logs/server.log</output>
      <!-- Fail if not started/stopped within 30 sec -->
      <timeout>30000</timeout>
    </container>
    <configuration>
      <type>existing</type>
      <home>${glassfish.installDirectory}/glassfish</home>
      <properties>
        <cargo.glassfish.domain.name>${glassfish.domainName}</cargo.glassfish.domain.name>
        <cargo.remote.username>${glassfish.adminUser}</cargo.remote.username>
        <cargo.remote.passwordFile>${glassfish.installDirectory}/admin.password</cargo.remote.passwordFile>
        <!-- Maven sets java.home property to JRE but we want JDK -->
      </properties>
    </configuration>
    <deployables>
      <deployable>
        <groupId>${project.groupId}</groupId>
        <artifactId>${project.artifactId}</artifactId>
        <type>${project.packaging}</type>
        <properties>
          <context>/${project.artifactId}</context>
        </properties>
      </deployable>
    </deployables>
  </configuration>
</plugin>

Debug log

[DEBUG] [2.ContainerStartMojo] Resolved artifact and dependencies:file:/Users/Abhijit/Repositories/maven/org/codehaus/cargo/cargo-core-container-glassfish/1.4.5/cargo-core-container-glassfish-1.4.5.jar]
[INFO] [2.ContainerStartMojo] Resolved container artifact org.codehaus.cargo:cargo-core-container-glassfish:jar:1.4.5 for container glassfish4x
[DEBUG] Scheduling deployable for deployment: [groupId [name.abhijitsarkar.learning.webservices.jaxws.security], artifactId [calculator-enc], type [war], location [null], pingURL [null]]
[DEBUG] Initial deployable values: groupId = [name.abhijitsarkar.learning.webservices.jaxws.security], artifactId = [calculator-enc], type = [war], location = [null]
[DEBUG] Searching for an artifact that matches [name.abhijitsarkar.learning.webservices.jaxws.security:calculator-enc:war:null]...
[DEBUG] Checking artifact [name.abhijitsarkar.learning.webservices.jaxws.security:calculator-enc:war:null]...
[DEBUG] Computed deployable values: groupId = [name.abhijitsarkar.learning.webservices.jaxws.security], artifactId = [calculator-enc], classifier = [null], type = [war], location = [/Users/Abhijit/Repositories/git/java-ee/jaxws-security/calculator-enc/target/calculator-enc-0.0.1-SNAPSHOT.war]
[DEBUG] Setting deployable property [context]:[/calculator-enc] for [/Users/Abhijit/Repositories/git/java-ee/jaxws-security/calculator-enc/target/calculator-enc-0.0.1-SNAPSHOT.war]
[DEBUG] Invoking setter method public synchronized void org.codehaus.cargo.container.deployable.WAR.setContext(java.lang.String) for deployable org.codehaus.cargo.container.deployable.WAR[calculator-enc-0.0.1-SNAPSHOT.war] with argument /calculator-enc
[DEBUG] Setting container timeout to [30000]

Answer 1

For others who may come across this issue, it took me 2 days of debugging through Cargo src code to figure out the problem. The two <home> locations are actually both needed. The one under <container> should point to the GlassFish outer installation directory (that contains another glassfish directory inside) and the one under <configuration> should point to the glassfish/domains directory. Has anyone ever mentioned to them that the naming convention is terrible? Why not call the later '<home>' <domainsDir> or something that actually means what it reads?