Cargo
  1. Cargo
  2. CARGO-1102

jboss42x remote deploy failure: pointing to wrong war filename?

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 1.2.1
    • Fix Version/s: None
    • Component/s: JBoss, Maven2
    • Labels:
      None
    • Environment:
      Mac 10.6.8, Ubuntu 11.10
    • Complexity:
      Intermediate
    • Number of attachments :
      3

      Description

      I only see failure when I'm trying to remote deploy to a JBoss 4.2.3 GA instance. I've ensured the servers can speak to each other, and I've manually placed a war on the deploying server's normal (port 80) webserver and manually crafted the URL the Cargo makes to hit it, and that works fine, too. So all connectivity seems fine.

      The only things that seems to me to be wrong is that the filename in the URL in the example at http://cargo.codehaus.org/JBoss+Remote+Deployer#JBossRemoteDeployer-JBoss40xand42x contains "-1.0-SNAPSHOT" and even though I am trying to deploy a snapshot, too, I only have "fly-garmin.war" with no version or "-SHAPSHOT".

      Here is what I have in my POM...

      <plugin>  
        <groupId>org.codehaus.cargo</groupId>  
        <artifactId>cargo-maven2-plugin</artifactId> 
        <version>1.2.1</version> 
        <configuration>  
          <container>  
            <containerId>jboss42x</containerId>  
            <type>remote</type>  
          </container>
          <configuration>  
            <type>runtime</type>  
            <properties>
              <cargo.remote.username>foo</cargo.remote.username>
              <cargo.remote.password>bar</cargo.remote.password>
              <cargo.hostname>dflyproxy.garmin.com</cargo.hostname>
              <cargo.servlet.port>80</cargo.servlet.port>
              <cargo.jboss.remotedeploy.port>8980</cargo.jboss.remotedeploy.port>
              <cargo.logging>high</cargo.logging>
            </properties> 
          </configuration>  
        </configuration>  
        <executions>
          <execution>
            <id>start-container</id>
            <phase>pre-integration-test</phase>
            <goals>
              <goal>deploy</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
      
      1. logged-failure.txt
        20 kB
        Ken Martin
      2. logged-success.txt
        35 kB
        Ken Martin
      3. new-logged-failure.txt
        38 kB
        Ken Martin

        Activity

        Hide
        Ken Martin added a comment -

        A little more info... if I hardcode the IP of the deploying server it works... once. So, for example, I do this...

        <cargo.jboss.remotedeploy.hostname>111.222.333.1</cargo.jboss.remotedeploy.hostname>
        <cargo.jboss.remotedeploy.port>8980</cargo.jboss.remotedeploy.port>

        ...and it works. Then if I run it again, it fails with this...

        [DEBUG] [SimpleHttpFileServer] Waiting for connection on socket ServerSocket[addr=/111.222.333.1,port=0,localport=8980]
        [INFO] ------------------------------------------------------------------------
        [INFO] BUILD FAILURE
        [INFO] ------------------------------------------------------------------------
        [INFO] Total time: 23.764s
        [INFO] Finished at: Wed Apr 18 15:44:09 CDT 2012
        [INFO] Final Memory: 16M/160M
        [INFO] ------------------------------------------------------------------------
        [ERROR] Failed to execute goal org.codehaus.cargo:cargo-maven2-plugin:1.2.1:deploy (start-container) on project com-flygarmin: Execution start-container of goal org.codehaus.cargo:cargo-maven2-plugin:1.2.1:deploy failed: Application server didn't request the file -> [Help 1]
        org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.cargo:cargo-maven2-plugin:1.2.1:deploy (start-container) on project com-flygarmin: Execution start-container of goal org.codehaus.cargo:cargo-maven2-plugin:1.2.1:deploy failed: Application server didn't request the file

        ...then if I change the port number like this...

        <cargo.jboss.remotedeploy.port>8981</cargo.jboss.remotedeploy.port>

        ...and run it again, it works.

        Show
        Ken Martin added a comment - A little more info... if I hardcode the IP of the deploying server it works... once. So, for example, I do this... <cargo.jboss.remotedeploy.hostname>111.222.333.1</cargo.jboss.remotedeploy.hostname> <cargo.jboss.remotedeploy.port>8980</cargo.jboss.remotedeploy.port> ...and it works. Then if I run it again, it fails with this... [DEBUG] [SimpleHttpFileServer] Waiting for connection on socket ServerSocket [addr=/111.222.333.1,port=0,localport=8980] [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 23.764s [INFO] Finished at: Wed Apr 18 15:44:09 CDT 2012 [INFO] Final Memory: 16M/160M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.codehaus.cargo:cargo-maven2-plugin:1.2.1:deploy (start-container) on project com-flygarmin: Execution start-container of goal org.codehaus.cargo:cargo-maven2-plugin:1.2.1:deploy failed: Application server didn't request the file -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.cargo:cargo-maven2-plugin:1.2.1:deploy (start-container) on project com-flygarmin: Execution start-container of goal org.codehaus.cargo:cargo-maven2-plugin:1.2.1:deploy failed: Application server didn't request the file ...then if I change the port number like this... <cargo.jboss.remotedeploy.port>8981</cargo.jboss.remotedeploy.port> ...and run it again, it works.
        Hide
        Savas Ali Tokmen added a comment -

        Hi Ken

        Can you please:

        1. Run Maven with the -X option and send the output log file?
        2. Check on JBoss side for messages regarding deployment?

        Thank you

        Show
        Savas Ali Tokmen added a comment - Hi Ken Can you please: Run Maven with the -X option and send the output log file? Check on JBoss side for messages regarding deployment? Thank you
        Hide
        Ken Martin added a comment -

        Thanks for looking at this, Savas. The attached output was obtained by using -X. Do you need more than that?

        I did look for something on the JBoss server, but saw no errors in logs. I may not be looking the in the right place, though, for the jmx-console logs?

        FWIW, there seem like two symptoms:

        [1] "Application server didn't request the file" which seems to mean it was never asked to, since it never seem to fail to request a file when it is hit with the request.

        [2] The application is hit with the request, but cannot see the file on the deploying server (so returns HTTP 500, a stack trace which includes "Is the file really on the server" or something like that).

        I think the [2] issues are gone as I finally have Ubuntu set up properly concerning etc/hosts.

        But [1] seems to be the problem. As thought SimpleHttpFileServer is starting up a server on a port, and then leaving it running beyond the deploy process. This makes sense because (a) a deploy started shortly after may have problems if that port is in use, and (b) I just saw last night an automated deploy work, even though it's last state was fail and everything, including the pom, was unchanged. After having been idle for many hours, it worked fine.

        Show
        Ken Martin added a comment - Thanks for looking at this, Savas. The attached output was obtained by using -X. Do you need more than that? I did look for something on the JBoss server, but saw no errors in logs. I may not be looking the in the right place, though, for the jmx-console logs? FWIW, there seem like two symptoms: [1] "Application server didn't request the file" which seems to mean it was never asked to, since it never seem to fail to request a file when it is hit with the request. [2] The application is hit with the request, but cannot see the file on the deploying server (so returns HTTP 500, a stack trace which includes "Is the file really on the server" or something like that). I think the [2] issues are gone as I finally have Ubuntu set up properly concerning etc/hosts. But [1] seems to be the problem. As thought SimpleHttpFileServer is starting up a server on a port, and then leaving it running beyond the deploy process. This makes sense because (a) a deploy started shortly after may have problems if that port is in use, and (b) I just saw last night an automated deploy work, even though it's last state was fail and everything, including the pom, was unchanged. After having been idle for many hours, it worked fine.
        Hide
        Savas Ali Tokmen added a comment -

        Hi Ken

        Can you please also send a log when the deploy operation does work? We can then spot the differences

        Thank you

        Show
        Savas Ali Tokmen added a comment - Hi Ken Can you please also send a log when the deploy operation does work? We can then spot the differences Thank you
        Hide
        Ken Martin added a comment -

        Here are two new logs. I first triggered a successful run by modifying the port number in the pom and committing. Once that was successful, I simply ran another build, which failed.

        In both files, it's line 327 that's the key point, I think.

        Show
        Ken Martin added a comment - Here are two new logs. I first triggered a successful run by modifying the port number in the pom and committing. Once that was successful, I simply ran another build, which failed. In both files, it's line 327 that's the key point, I think.
        Hide
        Ken Martin added a comment -

        I tried one more thing, too. After the failure, I completely restarted that computer, thinking that if it was a port left open, that should clear that out and then be successful. It was not. The build failed. So I don't think my "left open port" idea has any validity anymore.

        Show
        Ken Martin added a comment - I tried one more thing, too. After the failure, I completely restarted that computer, thinking that if it was a port left open, that should clear that out and then be successful. It was not. The build failed. So I don't think my "left open port" idea has any validity anymore.
        Hide
        Ken Martin added a comment -

        And I tried one more thing. I edited the pom to have a new port number and ran it... success. Then I "dirtied" the pom by removing a return and recommitted it triggering a new build... that failed. So it isn't that merely dirtying the pom triggers something so start fresh.

        Also, I've been running this using `mvn -U -X clean verify` every time.

        Show
        Ken Martin added a comment - And I tried one more thing. I edited the pom to have a new port number and ran it... success. Then I "dirtied" the pom by removing a return and recommitted it triggering a new build... that failed. So it isn't that merely dirtying the pom triggers something so start fresh. Also, I've been running this using `mvn -U -X clean verify` every time.
        Hide
        Ken Martin added a comment -

        One last note for the day: All those tests were running from Jenkins on Ubuntu. Just to remove some variables from the process, I did the same new port, run, success, rerun, failure from the command line on my Mac (10.6).

        Show
        Ken Martin added a comment - One last note for the day: All those tests were running from Jenkins on Ubuntu. Just to remove some variables from the process, I did the same new port, run, success, rerun, failure from the command line on my Mac (10.6).
        Hide
        Savas Ali Tokmen added a comment -

        Hi Ken

        The logs are interesting and give the impression that the JBoss server is not requesting the file -maybe it thinks it got it from its cache?

        Can you check the server log? Normally, just like in the http://bamboo.ci.codehaus.org/artifact/CARGO-SAMPLESJBOSS42X/JOB1/build-688/Container-logs/jboss42x/remote/RemoteDeploymentTest/testDeployUndeployRedeployWarRemotely/container/log/server.log example, you should see messages like:

        2012-04-21 09:03:43,313 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment of package: http://codehaus04.managed.contegix.com:54221/simple-war-1.2.2-SNAPSHOT.war
        2012-04-21 09:03:43,313 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment (init step) of package at: http://codehaus04.managed.contegix.com:54221/simple-war-1.2.2-SNAPSHOT.war
        2012-04-21 09:03:43,313 DEBUG [org.jboss.deployment.MainDeployer] Copying http://codehaus04.managed.contegix.com:54221/simple-war-1.2.2-SNAPSHOT.war -> /opt/j2ee/domains/ci.codehaus.org/bamboo/webapps/atlassian-bamboo/data/atlassian-bamboo-3.4.4/xml-data/build-dir/CARGO-SAMPLESJBOSS42X-JOB1/core/samples/java/target/jboss42x/remote/RemoteDeploymentTest/testDeployUndeployRedeployWarRemotely/container/tmp/deploy/tmp12819simple-war-1.2.2-SNAPSHOT.war
        2012-04-21 09:03:43,314 DEBUG [org.jboss.deployment.MainDeployer] using deployer MBeanProxyExt[jboss.web:service=WebServer]
        

        Thank you

        Show
        Savas Ali Tokmen added a comment - Hi Ken The logs are interesting and give the impression that the JBoss server is not requesting the file -maybe it thinks it got it from its cache? Can you check the server log? Normally, just like in the http://bamboo.ci.codehaus.org/artifact/CARGO-SAMPLESJBOSS42X/JOB1/build-688/Container-logs/jboss42x/remote/RemoteDeploymentTest/testDeployUndeployRedeployWarRemotely/container/log/server.log example, you should see messages like: 2012-04-21 09:03:43,313 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment of package: http://codehaus04.managed.contegix.com:54221/simple-war-1.2.2-SNAPSHOT.war 2012-04-21 09:03:43,313 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment (init step) of package at: http://codehaus04.managed.contegix.com:54221/simple-war-1.2.2-SNAPSHOT.war 2012-04-21 09:03:43,313 DEBUG [org.jboss.deployment.MainDeployer] Copying http://codehaus04.managed.contegix.com:54221/simple-war-1.2.2-SNAPSHOT.war -> /opt/j2ee/domains/ci.codehaus.org/bamboo/webapps/atlassian-bamboo/data/atlassian-bamboo-3.4.4/xml-data/build-dir/CARGO-SAMPLESJBOSS42X-JOB1/core/samples/java/target/jboss42x/remote/RemoteDeploymentTest/testDeployUndeployRedeployWarRemotely/container/tmp/deploy/tmp12819simple-war-1.2.2-SNAPSHOT.war 2012-04-21 09:03:43,314 DEBUG [org.jboss.deployment.MainDeployer] using deployer MBeanProxyExt[jboss.web:service=WebServer] Thank you
        Hide
        Ken Martin added a comment -

        Sorry for the delay... I had to take my mind off of deploy processes and actually get some work done.

        I will check this today.

        Show
        Ken Martin added a comment - Sorry for the delay... I had to take my mind off of deploy processes and actually get some work done. I will check this today.
        Hide
        Ken Martin added a comment -

        OK I tailed the log and watched it all go. The server instance is indeed asking the deploying server for the file, not finding it, and throwing the 500 we've seen in the log. Server-side log entry is below. I then stopped tailing and pinged the deploying server, that was just fine.

        So, I believe:

        • the machines are having no problem seeing each other
        • cargo is getting the request to the server jmx-console
        • the request is attempted, but the cargo server cannot fulfill it

        2012-04-27 10:06:13,316 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/jmx-console].[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
        org.jboss.deployment.DeploymentException: url http://direwolf:8972/fly-garmin.war could not be opened, does it exist?
        at org.jboss.deployment.DeploymentInfo.<init>(DeploymentInfo.java:214)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:781)
        at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:258)
        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdaptorServlet.java:303)
        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:102)
        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doGet(HtmlAdaptorServlet.java:77)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
        at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:437)
        at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:366)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
        at java.lang.Thread.run(Thread.java:619)

        Show
        Ken Martin added a comment - OK I tailed the log and watched it all go. The server instance is indeed asking the deploying server for the file, not finding it, and throwing the 500 we've seen in the log. Server-side log entry is below. I then stopped tailing and pinged the deploying server, that was just fine. So, I believe: the machines are having no problem seeing each other cargo is getting the request to the server jmx-console the request is attempted, but the cargo server cannot fulfill it 2012-04-27 10:06:13,316 ERROR [org.apache.catalina.core.ContainerBase. [jboss.web] . [localhost] . [/jmx-console] . [HtmlAdaptor] ] Servlet.service() for servlet HtmlAdaptor threw exception org.jboss.deployment.DeploymentException: url http://direwolf:8972/fly-garmin.war could not be opened, does it exist? at org.jboss.deployment.DeploymentInfo.<init>(DeploymentInfo.java:214) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:781) at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:258) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdaptorServlet.java:303) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:102) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doGet(HtmlAdaptorServlet.java:77) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262) at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:437) at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:366) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446) at java.lang.Thread.run(Thread.java:619)
        Hide
        Ken Martin added a comment -

        More data. If I change the cargo.jboss.remotedeploy.port so something new (which has been my reliable hack to get this to build and deploy), it works. I tailed the server logs when this successful deploy attempt happens, and I got this (much like your example):

        2012-04-27 12:06:40,699 DEBUG [org.jboss.deployment.MainDeployer] using deployer MBeanProxyExt[jboss.web:service=WebServer]
        2012-04-27 12:06:40,700 DEBUG [org.jboss.web.tomcat.service.JBossWeb] Begin init
        2012-04-27 12:06:40,703 DEBUG [org.jboss.web.tomcat.service.JBossWeb] Unpacking war to: /var/spool/dev/jboss/deploy/tmp1821720021071560691fly-garmin-exp.war
        2012-04-27 12:06:46,858 DEBUG [org.jboss.web.tomcat.service.JBossWeb] Replaced war with unpacked contents
        2012-04-27 12:06:46,858 DEBUG [org.jboss.web.tomcat.service.JBossWeb] Deleted war archive
        2012-04-27 12:06:46,858 DEBUG [org.jboss.web.tomcat.service.JBossWeb] webContext: null
        2012-04-27 12:06:46,859 DEBUG [org.jboss.web.tomcat.service.JBossWeb] warURL: file:/var/spool/dev/jboss/deploy/tmp1821720021071560691fly-garmin-exp.war/
        2012-04-27 12:06:46,889 DEBUG [org.jboss.web.tomcat.service.JBossWeb] End init

        Show
        Ken Martin added a comment - More data. If I change the cargo.jboss.remotedeploy.port so something new (which has been my reliable hack to get this to build and deploy), it works. I tailed the server logs when this successful deploy attempt happens, and I got this (much like your example): 2012-04-27 12:06:40,699 DEBUG [org.jboss.deployment.MainDeployer] using deployer MBeanProxyExt [jboss.web:service=WebServer] 2012-04-27 12:06:40,700 DEBUG [org.jboss.web.tomcat.service.JBossWeb] Begin init 2012-04-27 12:06:40,703 DEBUG [org.jboss.web.tomcat.service.JBossWeb] Unpacking war to: /var/spool/dev/jboss/deploy/tmp1821720021071560691fly-garmin-exp.war 2012-04-27 12:06:46,858 DEBUG [org.jboss.web.tomcat.service.JBossWeb] Replaced war with unpacked contents 2012-04-27 12:06:46,858 DEBUG [org.jboss.web.tomcat.service.JBossWeb] Deleted war archive 2012-04-27 12:06:46,858 DEBUG [org.jboss.web.tomcat.service.JBossWeb] webContext: null 2012-04-27 12:06:46,859 DEBUG [org.jboss.web.tomcat.service.JBossWeb] warURL: file:/var/spool/dev/jboss/deploy/tmp1821720021071560691fly-garmin-exp.war/ 2012-04-27 12:06:46,889 DEBUG [org.jboss.web.tomcat.service.JBossWeb] End init
        Hide
        Savas Ali Tokmen added a comment -

        Hi Ken

        Does changing the port work at each time?

        Thank you

        Show
        Savas Ali Tokmen added a comment - Hi Ken Does changing the port work at each time? Thank you
        Hide
        Ken Martin added a comment -

        Yes

        Show
        Ken Martin added a comment - Yes
        Hide
        Savas Ali Tokmen added a comment -

        Hi Ken

        OK, I would then propose to close this ticket as "Cannot reproduce", and if you want add a note in the JBoss remote deployer's documentation.

        Agree?

        Cheers

        Show
        Savas Ali Tokmen added a comment - Hi Ken OK, I would then propose to close this ticket as "Cannot reproduce", and if you want add a note in the JBoss remote deployer's documentation. Agree? Cheers
        Hide
        Ken Martin added a comment -

        Well, I suppose we could, but that means this really doesn't work for continuous integration, which is what we'd like to be doing with it.

        Is there anything I can do to better log what's happening with SimpleFileServer? If it has errors, where might they be written to?

        Show
        Ken Martin added a comment - Well, I suppose we could, but that means this really doesn't work for continuous integration, which is what we'd like to be doing with it. Is there anything I can do to better log what's happening with SimpleFileServer? If it has errors, where might they be written to?
        Hide
        Savas Ali Tokmen added a comment -

        Hi Ken

        For the ports, you can use the org.codehaus.mojo:build-helper-maven-plugin's reserve-network-port goal; this way it will always reserve some unused ports. Example: http://svn.codehaus.org/cargo/extensions/trunk/maven2/samples/pom.xml

        Else, if you run mvn with the -X option, you will see the log messages listed in: http://svn.codehaus.org/cargo/core/trunk/containers/jboss/src/main/java/org/codehaus/cargo/container/jboss/internal/SimpleHttpFileServer.java

        Cheers

        Show
        Savas Ali Tokmen added a comment - Hi Ken For the ports, you can use the org.codehaus.mojo:build-helper-maven-plugin's reserve-network-port goal; this way it will always reserve some unused ports. Example: http://svn.codehaus.org/cargo/extensions/trunk/maven2/samples/pom.xml Else, if you run mvn with the -X option, you will see the log messages listed in: http://svn.codehaus.org/cargo/core/trunk/containers/jboss/src/main/java/org/codehaus/cargo/container/jboss/internal/SimpleHttpFileServer.java Cheers
        Hide
        Savas Ali Tokmen added a comment -

        Hi Ken

        Any news?

        Cheers

        Show
        Savas Ali Tokmen added a comment - Hi Ken Any news? Cheers
        Hide
        Savas Ali Tokmen added a comment -

        Issue cannot be reproduced when org.codehaus.mojo:build-helper-maven-plugin's reserve-network-port goal is used (i.e., reserved unused ports are always used).

        Example: http://svn.codehaus.org/cargo/extensions/trunk/maven2/samples/pom.xml

        Show
        Savas Ali Tokmen added a comment - Issue cannot be reproduced when org.codehaus.mojo:build-helper-maven-plugin's reserve-network-port goal is used (i.e., reserved unused ports are always used). Example: http://svn.codehaus.org/cargo/extensions/trunk/maven2/samples/pom.xml

          People

          • Assignee:
            Unassigned
            Reporter:
            Ken Martin
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: