Cargo
  1. Cargo
  2. CARGO-416

JMX deployer currently uses the same path on the local filesystem and on the server one

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.3-maven2
    • Fix Version/s: 1.0.3
    • Component/s: JBoss, Maven2
    • Labels:
      None
    • Complexity:
      Intermediate
    • Tested on JDKs:
      1.5
    • Number of attachments :
      9

      Description

      I have trouble deploying to a remote JBoss server using the cargo-maven2 plugin from my local PC. I have posted on the cargo newsgroup and received this answer:

      "Your configuration looks good. I've just checked the source code the JBoss remote deployer (JBossRemoteDeployer.java class) and there are 2 things:

      • We're using the JBoss JMX deployer which requires the deployable to be deployed to be present on the server filesystem.
      • The location used by our JMX deployer currently uses the same path on the local filesystem and on the server one. This is a bad limitation (I'm surprised nobody raised this before). I'd suggest you create a JIRA issue for this.

      The current solution I can think of would be to create a JBossDeployable class that extends Deployable and adds a setRemoteFile(String) method. For a m2 user this would mean configuring it like this:

      <deployable>
      [...]
      <properties>
      <remoteFile>...</remoteFile>
      </properties>
      </deployable>

      However we really need to find a way to deploy a local file to a remote JBoss server. This would remove the need for this JBossDeployable class and would be much easier.

      Thanks

      -Vincent
      "

      I also think there should be an improvement to this plugin to allow remote deployments from local PCs.

      1. CARGO-416.patch
        28 kB
        Adrian Cole
      2. CARGO-416-V102-CORE.patch
        31 kB
        cedric ghanassia
      3. CARGO-416-V102-CORE.patch
        21 kB
        cedric ghanassia
      4. CARGO-416-V102-EXTENSION.patch
        0.9 kB
        cedric ghanassia
      5. jboss-remote-deploy.patch
        20 kB
        Thor ge Eldby
      6. JettyHTTPFileServerTest.java
        0.7 kB
        Nicolas Jouanin

        Activity

        Hide
        Randal Cobb added a comment -

        I'm seeing this same problem with JBoss 4.0.4. In my case, Continuum is running a nightly m2 build that does nothing more than a cargo:redeploy of an ear file. I see in the logs that it is in the process of deploying the WAR file inside the EAR when it happens to me. The wrapper class (mentioned above) doesn't seem to help in my case.

        If it matters, this is a linux workstation with jboss installed locally and using the following pom configuration:
        <plugin>
        <groupId>org.codehaus.cargo</groupId>
        <artifactId>cargo-maven2-plugin</artifactId>
        <configuration>
        <container>
        <containerId>jboss4x</containerId>
        <type>remote</type>
        <timeout>240000</timeout>
        </container>
        <configuration>
        <type>runtime</type>
        </configuration>
        <deployer>
        <deployables>
        <deployable>
        <groupId>com.company.projectGroup</groupId>
        <artifactId>projectEAR</artifactId>
        <type>ear</type>
        </deployable>
        </deployables>
        </deployer>
        </configuration>
        </plugin>

        Show
        Randal Cobb added a comment - I'm seeing this same problem with JBoss 4.0.4. In my case, Continuum is running a nightly m2 build that does nothing more than a cargo:redeploy of an ear file. I see in the logs that it is in the process of deploying the WAR file inside the EAR when it happens to me. The wrapper class (mentioned above) doesn't seem to help in my case. If it matters, this is a linux workstation with jboss installed locally and using the following pom configuration: <plugin> <groupId>org.codehaus.cargo</groupId> <artifactId>cargo-maven2-plugin</artifactId> <configuration> <container> <containerId>jboss4x</containerId> <type>remote</type> <timeout>240000</timeout> </container> <configuration> <type>runtime</type> </configuration> <deployer> <deployables> <deployable> <groupId>com.company.projectGroup</groupId> <artifactId>projectEAR</artifactId> <type>ear</type> </deployable> </deployables> </deployer> </configuration> </plugin>
        Hide
        Matt Wringe added a comment -

        The problem here is that the jmx deployer doesn't accept a file as a parameter, but a url. This makes it difficult to upload a file to the server remotely.

        We are going to have to either to create an http/ftp server and make the war available so that the jmx deployer can grab it from the url (this is probably the easiest solution, but opens up some security issues), or completely rethink how we are going to handle remote deployment for JBoss (perhaps using something like the Tomcat Manager).

        Show
        Matt Wringe added a comment - The problem here is that the jmx deployer doesn't accept a file as a parameter, but a url. This makes it difficult to upload a file to the server remotely. We are going to have to either to create an http/ftp server and make the war available so that the jmx deployer can grab it from the url (this is probably the easiest solution, but opens up some security issues), or completely rethink how we are going to handle remote deployment for JBoss (perhaps using something like the Tomcat Manager).
        Hide
        Thor ge Eldby added a comment -

        Hi
        I've created a patch for jboss remote deploy (see attached jboss-remote-deploy.patch). It implements some changes to the Carge Core JBoss Container and may be patched at core/containers/jboss. It is done by setting up an ad-hoc Jetty resource handler and instruct JBoss to retrieve the deployable from that. I've only had opportunity to test it with JBoss 4.0.5.

        Show
        Thor ge Eldby added a comment - Hi I've created a patch for jboss remote deploy (see attached jboss-remote-deploy.patch). It implements some changes to the Carge Core JBoss Container and may be patched at core/containers/jboss. It is done by setting up an ad-hoc Jetty resource handler and instruct JBoss to retrieve the deployable from that. I've only had opportunity to test it with JBoss 4.0.5.
        Hide
        Matt Wringe added a comment -

        my only concern with this is that it should be done in a secure manner, or the user should be able to make it secure themselves.

        I think it should be fine as long as we make sure its well documented that its not being sent in a secure manner. Its at least better than the broken way we have now.

        Show
        Matt Wringe added a comment - my only concern with this is that it should be done in a secure manner, or the user should be able to make it secure themselves. I think it should be fine as long as we make sure its well documented that its not being sent in a secure manner. Its at least better than the broken way we have now.
        Hide
        Adrian Cole added a comment -

        I've read through the implementation and it seems to be a valid and clever workaround to the JBoss limitation as noted in thread http://www.jboss.com/index.html?module=bb&op=viewtopic&t=128025

        That said, it increases complexity, spawning a server thread that could die unexpectedly. It also opens configuration management of the listen host/port of jetty, which could easily collide on multi-purpose build machines. I suggest we leave this as a temporary measure until we get the design right.

        I think Vincent's original idea is doable: remoteFile. I might name it destination or the like, and have it optional. If present, it will accept a VFS url, which opens us up to local, cifs, sftp, ftp, webdav and other implementations of file systems. In this regard, we don't have to write/test file system code.

        Thoughts?

        Show
        Adrian Cole added a comment - I've read through the implementation and it seems to be a valid and clever workaround to the JBoss limitation as noted in thread http://www.jboss.com/index.html?module=bb&op=viewtopic&t=128025 That said, it increases complexity, spawning a server thread that could die unexpectedly. It also opens configuration management of the listen host/port of jetty, which could easily collide on multi-purpose build machines. I suggest we leave this as a temporary measure until we get the design right. I think Vincent's original idea is doable: remoteFile. I might name it destination or the like, and have it optional. If present, it will accept a VFS url, which opens us up to local, cifs, sftp, ftp, webdav and other implementations of file systems. In this regard, we don't have to write/test file system code. Thoughts?
        Hide
        Gabriele Columbro added a comment -

        I'm applying this fix locally to be able to deploy to a remote build server in the CI environment.

        Any idea to apply a fix version? I'd really go for it, as for now it will solve many infrastructural problems and allow cargo to be much more widespread in enterprise jboss based environments.

        In addition to that, it's not easy to maintain a patched snapshot (or with a classifier) version of cargo until this gets applied just for your development community.

        My 0.2.

        Ah, and thanks for the great patch. Genius.

        Show
        Gabriele Columbro added a comment - I'm applying this fix locally to be able to deploy to a remote build server in the CI environment. Any idea to apply a fix version? I'd really go for it, as for now it will solve many infrastructural problems and allow cargo to be much more widespread in enterprise jboss based environments. In addition to that, it's not easy to maintain a patched snapshot (or with a classifier) version of cargo until this gets applied just for your development community. My 0.2. Ah, and thanks for the great patch. Genius.
        Hide
        Nicolas Jouanin added a comment -

        My 0.2 comment :
        I've successfully applied the patch to the current SVN trunk version. Now deployable file is correctly downloaded to the server and successuflly deployed.
        I hope this patch can be integrated soon in the main trunk.

        Thanks again for this patch.

        Show
        Nicolas Jouanin added a comment - My 0.2 comment : I've successfully applied the patch to the current SVN trunk version. Now deployable file is correctly downloaded to the server and successuflly deployed. I hope this patch can be integrated soon in the main trunk. Thanks again for this patch.
        Hide
        Adrian Cole added a comment -

        I will clean up a few parameters in order to harden this for our 1.0 release. Here are the changes:

        rename property: DEPLOYABLE_HOST_PORT = "cargo.jboss.port" to
        REMOTEDEPLOY_PORT = "cargo.jboss.remotedeploy.port";
        -> change default from 18080 to 1+whatever the http port is. This will help reduce the number of configuration items needed in order to avoid port conflicts

        add property:
        REMOTEDEPLOY_ADDRESS = "cargo.jboss.remotedeploy.address";
        -> default is the local machine name, but as this isn't always preferred, we will allow an override

        Other changes:

        • Remove test cases that start an httpd process. These sort of test cases make things brittle and are better done with mocks.
        • Change to FileHandler() api as opposed to java.io. This is because FileHandler can be unit tested more easily.
        Show
        Adrian Cole added a comment - I will clean up a few parameters in order to harden this for our 1.0 release. Here are the changes: rename property: DEPLOYABLE_HOST_PORT = "cargo.jboss.port" to REMOTEDEPLOY_PORT = "cargo.jboss.remotedeploy.port"; -> change default from 18080 to 1+whatever the http port is. This will help reduce the number of configuration items needed in order to avoid port conflicts add property: REMOTEDEPLOY_ADDRESS = "cargo.jboss.remotedeploy.address"; -> default is the local machine name, but as this isn't always preferred, we will allow an override Other changes: Remove test cases that start an httpd process. These sort of test cases make things brittle and are better done with mocks. Change to FileHandler() api as opposed to java.io. This is because FileHandler can be unit tested more easily.
        Hide
        Adrian Cole added a comment -

        Here is a more cleaned-up version of the patch. It is better then before, but needs a lot better test coverage before we commit.

        Show
        Adrian Cole added a comment - Here is a more cleaned-up version of the patch. It is better then before, but needs a lot better test coverage before we commit.
        Hide
        Adrian Cole added a comment -

        the current patch is in better shape then the last. I'm looking for a volunteer to help increase the quality and test coverage on this before we commit to trunk.

        Show
        Adrian Cole added a comment - the current patch is in better shape then the last. I'm looking for a volunteer to help increase the quality and test coverage on this before we commit to trunk.
        Hide
        Nicolas Jouanin added a comment -

        I've some difficulties to include CARGO-416.patch as some path segments are unmatched when trying to apply the patch from Eclipse.
        Could you give me instructions on how to include it ? Should I apply this patch directly over the last checked out trunk version or should I first apply jboss-remote-deploy.patch ?

        Show
        Nicolas Jouanin added a comment - I've some difficulties to include CARGO-416 .patch as some path segments are unmatched when trying to apply the patch from Eclipse. Could you give me instructions on how to include it ? Should I apply this patch directly over the last checked out trunk version or should I first apply jboss-remote-deploy.patch ?
        Hide
        Adrian Cole added a comment -

        repaired patch. Please apply this in the following fashion.

        1. download to location you checked out trunks
        2. apply via "patch --binary -p0 -i CARGO-416.patch"

        note that if you don't have cygwin, and you are using windows, you can download patch.exe here: http://gnuwin32.sourceforge.net/packages/patch.htm

        Show
        Adrian Cole added a comment - repaired patch. Please apply this in the following fashion. 1. download to location you checked out trunks 2. apply via "patch --binary -p0 -i CARGO-416 .patch" note that if you don't have cygwin, and you are using windows, you can download patch.exe here: http://gnuwin32.sourceforge.net/packages/patch.htm
        Hide
        Nicolas Jouanin added a comment -

        Hi,
        I could apply the corrected patch successfully.
        First feedback :
        There seems to have an issue with the management of the URL in JettyHTTPFileServer because here is the error message I got back from JBoss when deploying :
        org.codehaus.cargo.container.ContainerException: Failed to deploy to [http://10.156.216.147:8080/jmx-console/HtmlAdaptor?action=invokeOpByName&name=jb
        oss.system:service%3DMainDeployer&methodName=deploy&argType=java.net.URL&arg0=http%3A%2F%2F10.156.220.90%3A18080paruemas-1.0-SNAPSHOT.war]
        You can see that there's an encoded '/' missing 18080 and paruemas-1.0-SNAPSHOT.war at the end of the URL.
        I will send a test case for this as attachement to this issue.
        Also note that it seems that this error only gets back when the deployable is declared with groupId and artifactId. When the deployable is a location (something like <location>target/cactified-$

        {project.build.finalName}

        .war</location>) , I have no feedback from jboss until URL invocation timeout.
        Here my modified version of JettyHTTPFileServer.buildUrl:
        protected URL buildUrl(InetSocketAddress listenSocket, String fileName)
        {
        try
        {
        String fullFileName = "";
        if (!fileName.startsWith("/"))

        { fullFileName = "/" + fileName; }

        else

        { fullFileName = fileName; }

        return new URL("http", listenSocket.getHostName(), listenSocket.getPort(),
        fullFileName);
        }
        catch (MalformedURLException e)

        { throw new CargoException("Could not create a url for " + listenSocket + " and file: " + fileName, e); }

        }

        With this correction, the deployable is successfully deployed on Jboss.

        Show
        Nicolas Jouanin added a comment - Hi, I could apply the corrected patch successfully. First feedback : There seems to have an issue with the management of the URL in JettyHTTPFileServer because here is the error message I got back from JBoss when deploying : org.codehaus.cargo.container.ContainerException: Failed to deploy to [http://10.156.216.147:8080/jmx-console/HtmlAdaptor?action=invokeOpByName&name=jb oss.system:service%3DMainDeployer&methodName=deploy&argType=java.net.URL&arg0=http%3A%2F%2F10.156.220.90%3A18080paruemas-1.0-SNAPSHOT.war] You can see that there's an encoded '/' missing 18080 and paruemas-1.0-SNAPSHOT.war at the end of the URL. I will send a test case for this as attachement to this issue. Also note that it seems that this error only gets back when the deployable is declared with groupId and artifactId. When the deployable is a location (something like <location>target/cactified-$ {project.build.finalName} .war</location>) , I have no feedback from jboss until URL invocation timeout. Here my modified version of JettyHTTPFileServer.buildUrl: protected URL buildUrl(InetSocketAddress listenSocket, String fileName) { try { String fullFileName = ""; if (!fileName.startsWith("/")) { fullFileName = "/" + fileName; } else { fullFileName = fileName; } return new URL("http", listenSocket.getHostName(), listenSocket.getPort(), fullFileName); } catch (MalformedURLException e) { throw new CargoException("Could not create a url for " + listenSocket + " and file: " + fileName, e); } } With this correction, the deployable is successfully deployed on Jboss.
        Hide
        Nicolas Jouanin added a comment -

        Stupid test case to show the URL management error in JettyHTTPFileServer.

        Show
        Nicolas Jouanin added a comment - Stupid test case to show the URL management error in JettyHTTPFileServer.
        Hide
        Nicolas Jouanin added a comment -

        Hi,

        Regarding my last comment saying that is the deployable was a location there were no feeback from Jboss, it seems that things are a bit different.
        In fact, whether the deployable is a location or an artifact, it is deployed remotelly only if maven is run in offline mode (-o). I don't know why, but if maven is not run with -o option, JbossRemoteDeployer.invokeUrl() doesn't return from the call to this.connection.connect(url, username, password); In offline mode this call comes back when correctly when the war has been deploed remotelly. Strange ...

        Show
        Nicolas Jouanin added a comment - Hi, Regarding my last comment saying that is the deployable was a location there were no feeback from Jboss, it seems that things are a bit different. In fact, whether the deployable is a location or an artifact, it is deployed remotelly only if maven is run in offline mode (-o). I don't know why, but if maven is not run with -o option, JbossRemoteDeployer.invokeUrl() doesn't return from the call to this.connection.connect(url, username, password); In offline mode this call comes back when correctly when the war has been deploed remotelly. Strange ...
        Hide
        Nicolas Jouanin added a comment -

        In complement to the previous comment, invokeURL only works if I don't have a proxy defined in settings.xml or if I run maven with the -o option.
        Otherwise I get the following exception, which only comes after some kind of timeout:

        2009-02-25 14:35:34.250::INFO: Started SocketConnector@10.156.220.90:18080
        [INFO] ------------------------------------------------------------------------
        [ERROR] FATAL ERROR
        [INFO] ------------------------------------------------------------------------
        [INFO] Failed to deploy to http://10.156.216.147:8080/jmx-console/HtmlAdaptor?action=invokeOpByName&name=jboss.system:service%3DMainDeployer&methodName=deploy&argType=java.net.URL&arg0=http%3A%2F%2F10.156.220.90%3A18080%2Fcactified-paruemas-1.0-ice-SNAPSHOT.war
        Server returned HTTP response code: 504 for URL: http://10.156.216.147:8080/jmx-console/HtmlAdaptor?action=invokeOpByName&name=jboss.system:service%3DMainDeployer&methodName=deploy&argType=java.net.URL&arg0=http%3A%2F%2F10.156.220.90%3A18080%2Fcactified-paruemas-1.0-ice-SNAPSHOT.war
        [INFO] ------------------------------------------------------------------------
        [INFO] Trace
        org.codehaus.cargo.container.ContainerException: Failed to deploy to http://10.156.216.147:8080/jmx-console/HtmlAdaptor?action=invokeOpByName&name=jboss.system:service%3DMainDeployer&methodName=deploy&argType=java.net.URL&arg0=http%3A%2F%2F10.156.220.90%3A18080%2Fcactified-paruemas-1.0-ice-SNAPSHOT.war
        at org.codehaus.cargo.container.jboss.internal.JdkHttpURLConnection.connect(JdkHttpURLConnection.java:58)
        at org.codehaus.cargo.container.jboss.JBossRemoteDeployer.invokeURL(JBossRemoteDeployer.java:275)
        at org.codehaus.cargo.container.jboss.JBossRemoteDeployer.invokeRemotely(JBossRemoteDeployer.java:200)
        at org.codehaus.cargo.container.jboss.JBossRemoteDeployer.deploy(JBossRemoteDeployer.java:164)
        at org.codehaus.cargo.maven2.DeployerDeployMojo.performDeployerActionOnSingleDeployable(DeployerDeployMojo.java:79)
        at org.codehaus.cargo.maven2.AbstractDeployerMojo.performDeployerActionOnAllDeployables(AbstractDeployerMojo.java:104)
        at org.codehaus.cargo.maven2.AbstractDeployerMojo.doExecute(AbstractDeployerMojo.java:47)
        at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:266)
        at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
        Caused by: java.io.IOException: Server returned HTTP response code: 504 for URL: http://10.156.216.147:8080/jmx-console/HtmlAdaptor?action=invokeOpByName&name=jboss.system:service%3DMainDeployer&methodName=deploy&argType=java.net.URL&arg0=http%3A%2F%2F10.156.220.90%3A18080%2Fcactified-paruemas-1.0-ice-SNAPSHOT.war
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1290)
        at org.codehaus.cargo.container.jboss.internal.JdkHttpURLConnection.connect(JdkHttpURLConnection.java:51)
        ... 25 more
        java.io.IOException: Server returned HTTP response code: 504 for URL: http://10.156.216.147:8080/jmx-console/HtmlAdaptor?action=invokeOpByName&name=jb
        oss.system:service%3DMainDeployer&methodName=deploy&argType=java.net.URL&arg0=http%3A%2F%2F10.156.220.90%3A18080%2Fcactified-paruemas-1.0-ice-SNAPSHOT
        .war
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1290)
        at org.codehaus.cargo.container.jboss.internal.JdkHttpURLConnection.connect(JdkHttpURLConnection.java:51)
        at org.codehaus.cargo.container.jboss.JBossRemoteDeployer.invokeURL(JBossRemoteDeployer.java:275)
        at org.codehaus.cargo.container.jboss.JBossRemoteDeployer.invokeRemotely(JBossRemoteDeployer.java:200)
        at org.codehaus.cargo.container.jboss.JBossRemoteDeployer.deploy(JBossRemoteDeployer.java:164)

        Show
        Nicolas Jouanin added a comment - In complement to the previous comment, invokeURL only works if I don't have a proxy defined in settings.xml or if I run maven with the -o option. Otherwise I get the following exception, which only comes after some kind of timeout: 2009-02-25 14:35:34.250::INFO: Started SocketConnector@10.156.220.90:18080 [INFO] ------------------------------------------------------------------------ [ERROR] FATAL ERROR [INFO] ------------------------------------------------------------------------ [INFO] Failed to deploy to http://10.156.216.147:8080/jmx-console/HtmlAdaptor?action=invokeOpByName&name=jboss.system:service%3DMainDeployer&methodName=deploy&argType=java.net.URL&arg0=http%3A%2F%2F10.156.220.90%3A18080%2Fcactified-paruemas-1.0-ice-SNAPSHOT.war Server returned HTTP response code: 504 for URL: http://10.156.216.147:8080/jmx-console/HtmlAdaptor?action=invokeOpByName&name=jboss.system:service%3DMainDeployer&methodName=deploy&argType=java.net.URL&arg0=http%3A%2F%2F10.156.220.90%3A18080%2Fcactified-paruemas-1.0-ice-SNAPSHOT.war [INFO] ------------------------------------------------------------------------ [INFO] Trace org.codehaus.cargo.container.ContainerException: Failed to deploy to http://10.156.216.147:8080/jmx-console/HtmlAdaptor?action=invokeOpByName&name=jboss.system:service%3DMainDeployer&methodName=deploy&argType=java.net.URL&arg0=http%3A%2F%2F10.156.220.90%3A18080%2Fcactified-paruemas-1.0-ice-SNAPSHOT.war at org.codehaus.cargo.container.jboss.internal.JdkHttpURLConnection.connect(JdkHttpURLConnection.java:58) at org.codehaus.cargo.container.jboss.JBossRemoteDeployer.invokeURL(JBossRemoteDeployer.java:275) at org.codehaus.cargo.container.jboss.JBossRemoteDeployer.invokeRemotely(JBossRemoteDeployer.java:200) at org.codehaus.cargo.container.jboss.JBossRemoteDeployer.deploy(JBossRemoteDeployer.java:164) at org.codehaus.cargo.maven2.DeployerDeployMojo.performDeployerActionOnSingleDeployable(DeployerDeployMojo.java:79) at org.codehaus.cargo.maven2.AbstractDeployerMojo.performDeployerActionOnAllDeployables(AbstractDeployerMojo.java:104) at org.codehaus.cargo.maven2.AbstractDeployerMojo.doExecute(AbstractDeployerMojo.java:47) at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:266) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: java.io.IOException: Server returned HTTP response code: 504 for URL: http://10.156.216.147:8080/jmx-console/HtmlAdaptor?action=invokeOpByName&name=jboss.system:service%3DMainDeployer&methodName=deploy&argType=java.net.URL&arg0=http%3A%2F%2F10.156.220.90%3A18080%2Fcactified-paruemas-1.0-ice-SNAPSHOT.war at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1290) at org.codehaus.cargo.container.jboss.internal.JdkHttpURLConnection.connect(JdkHttpURLConnection.java:51) ... 25 more java.io.IOException: Server returned HTTP response code: 504 for URL: http://10.156.216.147:8080/jmx-console/HtmlAdaptor?action=invokeOpByName&name=jb oss.system:service%3DMainDeployer&methodName=deploy&argType=java.net.URL&arg0=http%3A%2F%2F10.156.220.90%3A18080%2Fcactified-paruemas-1.0-ice-SNAPSHOT .war at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1290) at org.codehaus.cargo.container.jboss.internal.JdkHttpURLConnection.connect(JdkHttpURLConnection.java:51) at org.codehaus.cargo.container.jboss.JBossRemoteDeployer.invokeURL(JBossRemoteDeployer.java:275) at org.codehaus.cargo.container.jboss.JBossRemoteDeployer.invokeRemotely(JBossRemoteDeployer.java:200) at org.codehaus.cargo.container.jboss.JBossRemoteDeployer.deploy(JBossRemoteDeployer.java:164)
        Hide
        Nicolas Jouanin added a comment -

        Finally I think this proxy problem is not related specifically to cargo but to the way the proxy manages local address. I can workaround this problem by using nonProxyHosts, so that's just a matter of maven proxy settings.
        Now, i've been able to test the patch for several days and it's working fine. There's still the bug I mentioned on a previous comment concerning a missing '/' in the invoked URL, but this should be easy to fix.

        Show
        Nicolas Jouanin added a comment - Finally I think this proxy problem is not related specifically to cargo but to the way the proxy manages local address. I can workaround this problem by using nonProxyHosts, so that's just a matter of maven proxy settings. Now, i've been able to test the patch for several days and it's working fine. There's still the bug I mentioned on a previous comment concerning a missing '/' in the invoked URL, but this should be easy to fix.
        Hide
        cedric ghanassia added a comment -

        This problem isn't fixed in cargo v1.0.2, i propose a new patch on it.
        This patch fixes two other problems:
        1. Added the jetty dependency in maven2-plugin project, to avoid declaring it in
        your final project
        2. InetAddress.getHostName() doesn't give the same result on Windows OS or Linux OS
        2.1 On Windows: If you give the IP Address to build InetAddress the method getHostName() returns your machine name
        2.2 On Linux : If you give the IP Address to build InetAddress the method getHostName() returns your IP address

        As the hostname is usually not registered in your DNS, it's better touse the IP address instead of the hostname,
        so if the variable cargo.jboss.remotedeploy.address is set, this is exactly this value that will be used to build the arg0 variable in the URL to deploy your war.

        Show
        cedric ghanassia added a comment - This problem isn't fixed in cargo v1.0.2, i propose a new patch on it. This patch fixes two other problems: 1. Added the jetty dependency in maven2-plugin project, to avoid declaring it in your final project 2. InetAddress.getHostName() doesn't give the same result on Windows OS or Linux OS 2.1 On Windows: If you give the IP Address to build InetAddress the method getHostName() returns your machine name 2.2 On Linux : If you give the IP Address to build InetAddress the method getHostName() returns your IP address As the hostname is usually not registered in your DNS, it's better touse the IP address instead of the hostname, so if the variable cargo.jboss.remotedeploy.address is set, this is exactly this value that will be used to build the arg0 variable in the URL to deploy your war.
        Hide
        Eddie Yee added a comment -

        Can someone please provide detailed instructions on how to implement the patch and document how to use the new configurations? Thanks.

        Show
        Eddie Yee added a comment - Can someone please provide detailed instructions on how to implement the patch and document how to use the new configurations? Thanks.
        Hide
        Savas Ali Tokmen added a comment -

        Adding a dependency to Jetty in the Maven2 plugin is a terrible idea: CARGO is supposed NOT to depend on any container! Moreover, the patch adds a dependency to Jetty in the JBoss container, which looks weird. JBoss is not Jetty.

        As for the details of your patch:

        • It removes tests in containers/jboss/src/test/java/org/codehaus/cargo/container/jboss/JBossRemoteDeployerTest.java. That's bad.
        • It only changes indent in containers/jboss/src/main/java/org/codehaus/cargo/container/jboss/JBossInstalledLocalDeployer.java and containers/jboss/src/main/java/org/codehaus/cargo/container/jboss/internal/AbstractJBossInstalledLocalContainer.java. That's not related to CARGO-416.
        • The only "logical" changes are the ones in containers/jboss/src/main/java/org/codehaus/cargo/container/jboss/JBossRemoteDeployer.java, and that one contains indent changes (again).

        Finally, the patch depends on JettyHTTPFileServer and that one is not included.

        Can you please fix these and resubmit a patch?

        Cheers

        Show
        Savas Ali Tokmen added a comment - Adding a dependency to Jetty in the Maven2 plugin is a terrible idea: CARGO is supposed NOT to depend on any container! Moreover, the patch adds a dependency to Jetty in the JBoss container, which looks weird. JBoss is not Jetty. As for the details of your patch: It removes tests in containers/jboss/src/test/java/org/codehaus/cargo/container/jboss/JBossRemoteDeployerTest.java. That's bad. It only changes indent in containers/jboss/src/main/java/org/codehaus/cargo/container/jboss/JBossInstalledLocalDeployer.java and containers/jboss/src/main/java/org/codehaus/cargo/container/jboss/internal/AbstractJBossInstalledLocalContainer.java. That's not related to CARGO-416 . The only "logical" changes are the ones in containers/jboss/src/main/java/org/codehaus/cargo/container/jboss/JBossRemoteDeployer.java, and that one contains indent changes (again). Finally, the patch depends on JettyHTTPFileServer and that one is not included. Can you please fix these and resubmit a patch? Cheers
        Hide
        cedric ghanassia added a comment -

        Thank you to correct my mistake . In fact i forgot to put the new files in the patch CARGO-416-V102-CORE,
        you can download the correct patch in attachment.
        Otherwise, i nearly agree with you about jetty dependency. But in this case the jetty is not a container but a way to transfert the war on the remote JBoss.
        And if you don't add this dependancy you force the project to declare into their pom, and for maven it's a worse practice to let the project to guess the transitive dependancy

        Show
        cedric ghanassia added a comment - Thank you to correct my mistake . In fact i forgot to put the new files in the patch CARGO-416 -V102-CORE, you can download the correct patch in attachment. Otherwise, i nearly agree with you about jetty dependency. But in this case the jetty is not a container but a way to transfert the war on the remote JBoss. And if you don't add this dependancy you force the project to declare into their pom, and for maven it's a worse practice to let the project to guess the transitive dependancy
        Hide
        cedric ghanassia added a comment -

        How to apply the patch : CARGO-416-V102-CORE

        1. checkout http://svn.codehaus.org/cargo/core/tags/cargo-core-1.0.2
        2. go to your repository
        3. right click select TortoiseSVN-->Apply patch ...
        4. select the patch file : CARGO-416-V102-CORE
        5. right click on the popup and select : Patch All
        6. It's better to change all versions, like 1.0.2-PATCH
        7. open console
        8. mvn install or/and mvn deploy

        Do the same for the patch : CARGO-416-V102-EXTENSION (just for jetty dependancy)

        How use the remote deployment on JBoss :

        Add in your pom project for example :

        <plugin>
        <groupId>org.codehaus.cargo</groupId>
        <artifactId>cargo-maven2-plugin</artifactId>
        <version>1.0.2-PATCH</version>
        <executions>
        <execution>
        <id>deploying app : $

        {project.build.finalName}</id>
        <phase>pre-integration-test</phase>
        <goals>
        <goal>redeploy</goal>
        </goals>
        </execution>
        </executions>
        <configuration>
        <wait>false</wait>
        <container>
        <containerId>jboss4x</containerId>
        <type>remote</type>
        </container>
        <configuration>
        <type>runtime</type>
        <properties>
        <cargo.logging>high</cargo.logging>
        <cargo.hostname>${jboss4x.host}</cargo.hostname>
        <cargo.servlet.port>${jboss4x.servlet.port}</cargo.servlet.port>
        <cargo.rmi.port>${jboss4x.rmi.port}</cargo.rmi.port>
        <cargo.remote.username>${jboss4x.username}</cargo.remote.username>
        <cargo.remote.password>${jboss4x.password}</cargo.remote.password>
        <cargo.jboss.configuration>${jboss4x.configuration}</cargo.jboss.configuration>
        <cargo.jboss.remotedeploy.address>${jboss4x.remotedeploy.address}</cargo.jboss.remotedeploy.address>
        <cargo.jboss.remotedeploy.port>${jboss4x.remotedeploy.port}</cargo.jboss.remotedeploy.port>
        </properties>
        </configuration>
        <deployer>
        <type>remote</type>
        <deployables>
        <deployable>
        <pingURL>http://${jboss4x.host}:${jboss4x.servlet.port}/${project.build.finalName}

        /</pingURL>
        <properties>
        <context>/$

        {project.build.finalName}

        </context>
        </properties>
        </deployable>
        </deployables>
        </deployer>
        </configuration>
        </plugin>

        jboss4x.host = address of your remote JBoss
        jboss4x.servlet.port = port of your remote JBoss
        jboss4x.username and jboss4x.password = crendentials of your remote JBoss
        jboss4x.configuration = The JBoss configuration selected. Examples of valid values: "default", "all", "minimal".
        cargo.jboss.remotedeploy.address=address used to start jetty don't set if your hostname is in your DNS, or use the IP address of your machine
        cargo.jboss.remotedeploy.port=port used to start jetty, don't forget to open this port bettewen $cargo.jboss.remotedeploy.address and $jboss4x.host

        Show
        cedric ghanassia added a comment - How to apply the patch : CARGO-416 -V102-CORE 1. checkout http://svn.codehaus.org/cargo/core/tags/cargo-core-1.0.2 2. go to your repository 3. right click select TortoiseSVN-->Apply patch ... 4. select the patch file : CARGO-416 -V102-CORE 5. right click on the popup and select : Patch All 6. It's better to change all versions, like 1.0.2-PATCH 7. open console 8. mvn install or/and mvn deploy Do the same for the patch : CARGO-416 -V102-EXTENSION (just for jetty dependancy) How use the remote deployment on JBoss : Add in your pom project for example : <plugin> <groupId>org.codehaus.cargo</groupId> <artifactId>cargo-maven2-plugin</artifactId> <version>1.0.2-PATCH</version> <executions> <execution> <id>deploying app : $ {project.build.finalName}</id> <phase>pre-integration-test</phase> <goals> <goal>redeploy</goal> </goals> </execution> </executions> <configuration> <wait>false</wait> <container> <containerId>jboss4x</containerId> <type>remote</type> </container> <configuration> <type>runtime</type> <properties> <cargo.logging>high</cargo.logging> <cargo.hostname>${jboss4x.host}</cargo.hostname> <cargo.servlet.port>${jboss4x.servlet.port}</cargo.servlet.port> <cargo.rmi.port>${jboss4x.rmi.port}</cargo.rmi.port> <cargo.remote.username>${jboss4x.username}</cargo.remote.username> <cargo.remote.password>${jboss4x.password}</cargo.remote.password> <cargo.jboss.configuration>${jboss4x.configuration}</cargo.jboss.configuration> <cargo.jboss.remotedeploy.address>${jboss4x.remotedeploy.address}</cargo.jboss.remotedeploy.address> <cargo.jboss.remotedeploy.port>${jboss4x.remotedeploy.port}</cargo.jboss.remotedeploy.port> </properties> </configuration> <deployer> <type>remote</type> <deployables> <deployable> <pingURL> http://$ {jboss4x.host}:${jboss4x.servlet.port}/${project.build.finalName} /</pingURL> <properties> <context>/$ {project.build.finalName} </context> </properties> </deployable> </deployables> </deployer> </configuration> </plugin> jboss4x.host = address of your remote JBoss jboss4x.servlet.port = port of your remote JBoss jboss4x.username and jboss4x.password = crendentials of your remote JBoss jboss4x.configuration = The JBoss configuration selected. Examples of valid values: "default", "all", "minimal". cargo.jboss.remotedeploy.address=address used to start jetty don't set if your hostname is in your DNS, or use the IP address of your machine cargo.jboss.remotedeploy.port=port used to start jetty, don't forget to open this port bettewen $cargo.jboss.remotedeploy.address and $jboss4x.host
        Hide
        Savas Ali Tokmen added a comment -

        Hello Cdric

        Thank you for the improvement on the patch and for your descriptions.

        We still need to discuss more on this issue, I'm extremely surprised JBoss doesn't offer upload functions over JMX.

        One point I'm keen on is the port used by the embedded Jetty server.

        The fact that all tests are missing is also annoying.

        Any other comments?

        Cheers

        Show
        Savas Ali Tokmen added a comment - Hello Cdric Thank you for the improvement on the patch and for your descriptions. We still need to discuss more on this issue, I'm extremely surprised JBoss doesn't offer upload functions over JMX. One point I'm keen on is the port used by the embedded Jetty server. The fact that all tests are missing is also annoying. Any other comments? Cheers
        Hide
        Savas Ali Tokmen added a comment -

        Personally, I would actually have preferred to have an application on JBoss for upload, pretty much like the https://svn.codehaus.org/cargo/resources/trunk/jetty-7-and-onwards-deployer for Jetty.

        And, of course, the absence of the upload functionnality on JBoss is simply untolerable. I'm wondering if the JBoss Enterprise Edition has it, by chance

        Show
        Savas Ali Tokmen added a comment - Personally, I would actually have preferred to have an application on JBoss for upload, pretty much like the https://svn.codehaus.org/cargo/resources/trunk/jetty-7-and-onwards-deployer for Jetty. And, of course, the absence of the upload functionnality on JBoss is simply untolerable. I'm wondering if the JBoss Enterprise Edition has it, by chance
        Hide
        Savas Ali Tokmen added a comment -

        Just asked that to JBoss: http://community.jboss.org/message/555787

        If no good answer comes, I'll be opening a request for enhancement in the JBoss JIRA.

        Show
        Savas Ali Tokmen added a comment - Just asked that to JBoss: http://community.jboss.org/message/555787 If no good answer comes, I'll be opening a request for enhancement in the JBoss JIRA.
        Hide
        Savas Ali Tokmen added a comment -

        Looks like JBoss really doesn't have an MBean for uploads!

        I've also analysed the possibility of embedding Jetty, and unfortunately it is not possible: the "standard" way of using CARGO is the uberjar, which contains all Java files of all containers.

        If JBoss requires Jetty, that will need to be integrated into the uberjar. This will, in turn, have extremely weird consequences on the preexisting Jetty container.

        I guess the best idea is to implement our own Web Server. A very, very basic Web Server code can be found on http://www.java2s.com/Code/Java/Network-Protocol/ASimpleWebServer.htm for example.

        Show
        Savas Ali Tokmen added a comment - Looks like JBoss really doesn't have an MBean for uploads! I've also analysed the possibility of embedding Jetty, and unfortunately it is not possible: the "standard" way of using CARGO is the uberjar, which contains all Java files of all containers. If JBoss requires Jetty, that will need to be integrated into the uberjar. This will, in turn, have extremely weird consequences on the preexisting Jetty container. I guess the best idea is to implement our own Web Server. A very, very basic Web Server code can be found on http://www.java2s.com/Code/Java/Network-Protocol/ASimpleWebServer.htm for example.
        Hide
        Savas Ali Tokmen added a comment -

        Just commited a new revision that should handle this issue. It does NOT use Jetty but a simple HTTP server.

        Please test and report back.

        Cheers

        Show
        Savas Ali Tokmen added a comment - Just commited a new revision that should handle this issue. It does NOT use Jetty but a simple HTTP server. Please test and report back. Cheers
        Hide
        Savas Ali Tokmen added a comment -

        I've tested the patch with JBoss 5. It does NOT work, here is the exception on the JBoss side:

        08:08:50,414 INFO  [MainDeployer] deploy, url=http://192.168.0.12:58407/simple-war-1.0.3-SNAPSHOT.war
        08:08:50,414 WARN  [MainDeployer] Failed to deploy: http://192.168.0.12:58407/simple-war-1.0.3-SNAPSHOT.war
        java.io.IOException: No context factory for http://192.168.0.12:58407/simple-war-1.0.3-SNAPSHOT.war
        	at org.jboss.virtual.VFS.getVFS(VFS.java:244)
        	at org.jboss.virtual.VFS.createNewRoot(VFS.java:261)
        	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:826)
        	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        	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:157)
        	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        	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:668)
        	at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:258)
        	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$4.run(HtmlAdaptorServlet.java:391)
        	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$4.run(HtmlAdaptorServlet.java:389)
        	at java.security.AccessController.doPrivileged(Native Method)
        	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdaptorServlet.java:387)
        	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdaptorServlet.java:312)
        	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:106)
        	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doGet(HtmlAdaptorServlet.java:81)
        	at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
        	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        	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:235)
        	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
        	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
        	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
        	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
        	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:158)
        	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
        	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
        	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
        	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        	at java.lang.Thread.run(Thread.java:637)
        08:08:50,416 ERROR [[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
        java.io.IOException: No context factory for http://192.168.0.12:58407/simple-war-1.0.3-SNAPSHOT.war
        	at org.jboss.virtual.VFS.getVFS(VFS.java:244)
        	at org.jboss.virtual.VFS.createNewRoot(VFS.java:261)
        	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:826)
        	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        	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:157)
        	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        	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:668)
        	at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:258)
        	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$4.run(HtmlAdaptorServlet.java:391)
        	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$4.run(HtmlAdaptorServlet.java:389)
        	at java.security.AccessController.doPrivileged(Native Method)
        	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdaptorServlet.java:387)
        	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdaptorServlet.java:312)
        	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:106)
        	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doGet(HtmlAdaptorServlet.java:81)
        	at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
        	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        	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:235)
        	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
        	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
        	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
        	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
        	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:158)
        	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
        	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
        	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
        	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        	at java.lang.Thread.run(Thread.java:637)
        

        As you can see, the JBoss deployer does not accept remote URLs.

        Please tell me which version of JBoss you've tested with. Else, I'll unpatch as this actually breaks the JBoss container.

        Cheers

        Show
        Savas Ali Tokmen added a comment - I've tested the patch with JBoss 5. It does NOT work, here is the exception on the JBoss side: 08:08:50,414 INFO [MainDeployer] deploy, url=http://192.168.0.12:58407/simple-war-1.0.3-SNAPSHOT.war 08:08:50,414 WARN [MainDeployer] Failed to deploy: http://192.168.0.12:58407/simple-war-1.0.3-SNAPSHOT.war java.io.IOException: No context factory for http://192.168.0.12:58407/simple-war-1.0.3-SNAPSHOT.war at org.jboss.virtual.VFS.getVFS(VFS.java:244) at org.jboss.virtual.VFS.createNewRoot(VFS.java:261) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:826) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 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:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) 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:668) at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:258) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$4.run(HtmlAdaptorServlet.java:391) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$4.run(HtmlAdaptorServlet.java:389) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdaptorServlet.java:387) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdaptorServlet.java:312) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:106) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doGet(HtmlAdaptorServlet.java:81) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) 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:235) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) 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:158) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:637) 08:08:50,416 ERROR [[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception java.io.IOException: No context factory for http://192.168.0.12:58407/simple-war-1.0.3-SNAPSHOT.war at org.jboss.virtual.VFS.getVFS(VFS.java:244) at org.jboss.virtual.VFS.createNewRoot(VFS.java:261) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:826) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 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:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) 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:668) at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:258) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$4.run(HtmlAdaptorServlet.java:391) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$4.run(HtmlAdaptorServlet.java:389) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdaptorServlet.java:387) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdaptorServlet.java:312) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:106) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doGet(HtmlAdaptorServlet.java:81) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) 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:235) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) 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:158) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:637) As you can see, the JBoss deployer does not accept remote URLs. Please tell me which version of JBoss you've tested with. Else, I'll unpatch as this actually breaks the JBoss container. Cheers
        Hide
        Savas Ali Tokmen added a comment -

        Partially fixed Revision: 2413

        Tested with jboss4x and jobss42x on my machine.

        To try it out yourself, please checkout and compile the CARGO source on your machine.

        If this is too hard for you, I can also update the SNAPSHOTs repository.

        For now, the jboss5x, jboss51x and jboss6x containers do not work with this method because of the exception I've mentioned earlier.

        We shall now see how to solve the issue on jboss5x, jboss51x and jboss6x. In the case we cannot, I guess this issue will need to be marked as "wontfix".

        Show
        Savas Ali Tokmen added a comment - Partially fixed Revision: 2413 Tested with jboss4x and jobss42x on my machine. To try it out yourself, please checkout and compile the CARGO source on your machine. If this is too hard for you, I can also update the SNAPSHOTs repository. For now, the jboss5x, jboss51x and jboss6x containers do not work with this method because of the exception I've mentioned earlier. We shall now see how to solve the issue on jboss5x, jboss51x and jboss6x. In the case we cannot, I guess this issue will need to be marked as "wontfix".
        Hide
        Savas Ali Tokmen added a comment -

        Here's the exception trace on JBoss 6:

        11:20:49,412 INFO  [org.jboss.deployment.MainDeployer] deploy, url=http://192.168.0.12:59529/simple-war-1.0.3-SNAPSHOT.war
        11:20:49,456 INFO  [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/simple-war-1.0.3-SNAPSHOT
        11:20:49,469 ERROR [org.apache.catalina.core.StandardContext] Error starting static Resources: java.lang.IllegalArgumentException: Invalid or unreadable WAR file : /simple-war-1.0.3-SNAPSHOT.war
        	at org.apache.naming.resources.WARDirContext.setDocBase(WARDirContext.java:130) [:6.0.0.20100429-M3]
        	at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:3895) [:6.0.0.20100429-M3]
        	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4063) [:6.0.0.20100429-M3]
        	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:323) [:6.0.0.20100429-M3]
        	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:148) [:6.0.0.20100429-M3]
        	at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:462) [:6.0.0.20100429-M3]
        	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116) [:6.0.0.20100429-M3]
        	at org.jboss.web.deployers.WebModule.start(WebModule.java:95) [:6.0.0.20100429-M3]
        	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
        	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20]
        	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
        	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
        	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.Beta5]
        	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.Beta5]
        	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.Beta5]
        	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.Beta5]
        	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.Beta5]
        	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206) [:2.2.0.Alpha9]
        	at $Proxy41.start(Unknown Source)	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:53) [:2.2.0.Alpha9]
        	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:41) [:2.2.0.Alpha9]
        	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:377) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:301) [:2.2.0.Alpha9]
        	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2042) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1081) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1320) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1244) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1137) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:937) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:652) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.system.ServiceController.doChange(ServiceController.java:671) [:6.0.0.20100429-M3 (Build SVNTag:JBoss_6.0.0.20100429-M3 date: 20100502)]
        	at org.jboss.system.ServiceController.start(ServiceController.java:443) [:6.0.0.20100429-M3 (Build SVNTag:JBoss_6.0.0.20100429-M3 date: 20100502)]
        	at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:189) [:6.0.0.20100429-M3]
        	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:102) [:6.0.0.20100429-M3]
        	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:49) [:6.0.0.20100429-M3]
        	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) [:2.2.0.Alpha4]
        	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.Alpha4]
        	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.Alpha4]
        	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1857) [:2.2.0.Alpha4]
        	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1575) [:2.2.0.Alpha4]
        	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1596) [:2.2.0.Alpha4]
        	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1516) [:2.2.0.Alpha4]
        	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:377) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2042) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1081) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1320) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1244) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1137) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:937) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:652) [jboss-dependency.jar:2.2.0.Alpha9]
        	at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:2008) [:2.2.0.Alpha4]
        	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1101) [:2.2.0.Alpha4]
        	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.Alpha4]
        	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:370) [:6.0.0.20100429-M3]
        	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
        	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20]
        	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
        	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
        	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.Beta5]
        	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.Beta5]
        	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.Beta5]
        	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.Beta5]
        	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.Beta5]
        	at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:258)
        	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$4.run(HtmlAdaptorServlet.java:391)
        	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$4.run(HtmlAdaptorServlet.java:388)
        	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_20]
        	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdaptorServlet.java:387)
        	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdaptorServlet.java:312)
        	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:106)
        	at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doGet(HtmlAdaptorServlet.java:81)
        	at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [:1.0.0.Beta2]
        	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [:1.0.0.Beta2]
        	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:336) [:6.0.0.20100429-M3]
        	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.20100429-M3]
        	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:293) [:6.0.0.20100429-M3]
        	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [:6.0.0.20100429-M3]
        	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183) [:6.0.0.20100429-M3]
        	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95) [:6.0.0.20100429-M3]
        	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) [:6.0.0.20100429-M3]
        	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) [:6.0.0.20100429-M3]
        	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:6.0.0.20100429-M3]
        	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.20100429-M3]
        	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.20100429-M3]
        	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.20100429-M3]
        	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [:6.0.0.20100429-M3]
        	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:872) [:6.0.0.20100429-M3]
        	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [:6.0.0.20100429-M3]
        	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.20100429-M3]
        	at java.lang.Thread.run(Thread.java:637) [:1.6.0_20]
        
        Show
        Savas Ali Tokmen added a comment - Here's the exception trace on JBoss 6: 11:20:49,412 INFO [org.jboss.deployment.MainDeployer] deploy, url=http://192.168.0.12:59529/simple-war-1.0.3-SNAPSHOT.war 11:20:49,456 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/simple-war-1.0.3-SNAPSHOT 11:20:49,469 ERROR [org.apache.catalina.core.StandardContext] Error starting static Resources: java.lang.IllegalArgumentException: Invalid or unreadable WAR file : /simple-war-1.0.3-SNAPSHOT.war at org.apache.naming.resources.WARDirContext.setDocBase(WARDirContext.java:130) [:6.0.0.20100429-M3] at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:3895) [:6.0.0.20100429-M3] at org.apache.catalina.core.StandardContext.start(StandardContext.java:4063) [:6.0.0.20100429-M3] at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:323) [:6.0.0.20100429-M3] at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:148) [:6.0.0.20100429-M3] at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:462) [:6.0.0.20100429-M3] at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116) [:6.0.0.20100429-M3] at org.jboss.web.deployers.WebModule.start(WebModule.java:95) [:6.0.0.20100429-M3] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20] at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.Beta5] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.Beta5] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.Beta5] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.Beta5] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.Beta5] at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206) [:2.2.0.Alpha9] at $Proxy41.start(Unknown Source) at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:53) [:2.2.0.Alpha9] at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:41) [:2.2.0.Alpha9] at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:377) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:301) [:2.2.0.Alpha9] at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2042) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1081) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1320) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1244) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1137) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:937) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:652) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.system.ServiceController.doChange(ServiceController.java:671) [:6.0.0.20100429-M3 (Build SVNTag:JBoss_6.0.0.20100429-M3 date: 20100502)] at org.jboss.system.ServiceController.start(ServiceController.java:443) [:6.0.0.20100429-M3 (Build SVNTag:JBoss_6.0.0.20100429-M3 date: 20100502)] at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:189) [:6.0.0.20100429-M3] at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:102) [:6.0.0.20100429-M3] at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:49) [:6.0.0.20100429-M3] at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) [:2.2.0.Alpha4] at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.Alpha4] at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.Alpha4] at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1857) [:2.2.0.Alpha4] at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1575) [:2.2.0.Alpha4] at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1596) [:2.2.0.Alpha4] at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1516) [:2.2.0.Alpha4] at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:377) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2042) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1081) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1320) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1244) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1137) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:937) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:652) [jboss-dependency.jar:2.2.0.Alpha9] at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:2008) [:2.2.0.Alpha4] at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1101) [:2.2.0.Alpha4] at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.Alpha4] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:370) [:6.0.0.20100429-M3] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20] at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.Beta5] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.Beta5] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.Beta5] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.Beta5] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.Beta5] at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:258) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$4.run(HtmlAdaptorServlet.java:391) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$4.run(HtmlAdaptorServlet.java:388) at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_20] at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdaptorServlet.java:387) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdaptorServlet.java:312) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:106) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doGet(HtmlAdaptorServlet.java:81) at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [:1.0.0.Beta2] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [:1.0.0.Beta2] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:336) [:6.0.0.20100429-M3] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.20100429-M3] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:293) [:6.0.0.20100429-M3] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [:6.0.0.20100429-M3] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183) [:6.0.0.20100429-M3] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95) [:6.0.0.20100429-M3] at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) [:6.0.0.20100429-M3] at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) [:6.0.0.20100429-M3] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:6.0.0.20100429-M3] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.20100429-M3] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.20100429-M3] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.20100429-M3] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [:6.0.0.20100429-M3] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:872) [:6.0.0.20100429-M3] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [:6.0.0.20100429-M3] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.20100429-M3] at java.lang.Thread.run(Thread.java:637) [:1.6.0_20]
        Hide
        cedric ghanassia added a comment -

        I confirm, is not possible to deploy remotely a war application in JBoss 5.X
        However, with a few additional correction it's again possible.
        The solution is :

        • Rewrite the cargo-patch-416 using JSR88 implementation for JBoss
        • Expose your war application in simple http server
        • Modification of the class : org.jboss.deployment.spi.DeploymentManagerImpl.java :
        • The war file must not be search in the temporary file, but available by URL using protocol HTTP
          I need a few days to package properly this solution.

        I tested it on Jboss 4.x and 5.x with success

        JBoss 6 is still in milestone and this solution don't work yet.
        A JIRA is open : https://jira.jboss.org/browse/JBAS-7818?subTaskView=unresolved

        Don't hesitate to ask me for more details, or if you see a problem.

        Show
        cedric ghanassia added a comment - I confirm, is not possible to deploy remotely a war application in JBoss 5.X However, with a few additional correction it's again possible. The solution is : Rewrite the cargo-patch-416 using JSR88 implementation for JBoss Expose your war application in simple http server Modification of the class : org.jboss.deployment.spi.DeploymentManagerImpl.java : The war file must not be search in the temporary file, but available by URL using protocol HTTP I need a few days to package properly this solution. I tested it on Jboss 4.x and 5.x with success JBoss 6 is still in milestone and this solution don't work yet. A JIRA is open : https://jira.jboss.org/browse/JBAS-7818?subTaskView=unresolved Don't hesitate to ask me for more details, or if you see a problem.
        Hide
        Savas Ali Tokmen added a comment -

        Hello

        Well, I have an issue open on JBoss 5.0.x, 5.1.x and 6.0.0 Mx: https://jira.jboss.org/browse/JBAS-8319 where it is clear that remote deployment using http://xxx/ URLs does not work in any of these servers.

        I have asked JBoss people a question via http://community.jboss.org/message/555787 and I've been pointed out to http://community.jboss.org/wiki/ProfileServiceDeploymentManagerin5x

        I've created test projects on NetBeans for JBoss 5.0.x, 5.1.x and 6.0.0 Mx and got things working; with two HUGE issues:

        1. The JBoss remote deployment API has changed between 5.0.x and 5.1.x. There are no changes between 5.1.x and 6.0.0 Mx, thought; but we cannot build the deployers for 5.0.x and 5.1.x in the same Maven2 project since the API is different.
        2. That API relies on many, many JBoss classes that are not in the jbossall-client.jar.

        We will therefore need to:

        1. Create an abstract JBossDeployer API in the jboss container.
        2. Create a new Maven2 module for JBoss 5.0.x that implements the JBossDeployer API.
        3. Create a new Maven2 module for JBoss 5.1.x and 6.0.0 Mx that implements the JBossDeployer API.
        4. Include both modules in the uberjar as JAR files.
        5. When calling the deployer, create a classpath with the correct JAR + many JAR files from JBOSS_HOME (which will therefore need to be present on the filesystem).

        I'll try to do this. If anyone has a better idea, please let me know.

        Cheers

        Show
        Savas Ali Tokmen added a comment - Hello Well, I have an issue open on JBoss 5.0.x, 5.1.x and 6.0.0 Mx: https://jira.jboss.org/browse/JBAS-8319 where it is clear that remote deployment using http://xxx/ URLs does not work in any of these servers. I have asked JBoss people a question via http://community.jboss.org/message/555787 and I've been pointed out to http://community.jboss.org/wiki/ProfileServiceDeploymentManagerin5x I've created test projects on NetBeans for JBoss 5.0.x, 5.1.x and 6.0.0 Mx and got things working; with two HUGE issues: 1. The JBoss remote deployment API has changed between 5.0.x and 5.1.x. There are no changes between 5.1.x and 6.0.0 Mx, thought; but we cannot build the deployers for 5.0.x and 5.1.x in the same Maven2 project since the API is different. 2. That API relies on many, many JBoss classes that are not in the jbossall-client.jar. We will therefore need to: 1. Create an abstract JBossDeployer API in the jboss container. 2. Create a new Maven2 module for JBoss 5.0.x that implements the JBossDeployer API. 3. Create a new Maven2 module for JBoss 5.1.x and 6.0.0 Mx that implements the JBossDeployer API. 4. Include both modules in the uberjar as JAR files. 5. When calling the deployer, create a classpath with the correct JAR + many JAR files from JBOSS_HOME (which will therefore need to be present on the filesystem). I'll try to do this. If anyone has a better idea, please let me know. Cheers
        Hide
        Anders Hammar added a comment -

        5. Oh no! This is so un-Maven. What we should do instead is to have a dependency to the artifacts in the JBoss repository.

        Show
        Anders Hammar added a comment - 5. Oh no! This is so un-Maven. What we should do instead is to have a dependency to the artifacts in the JBoss repository.
        Hide
        Savas Ali Tokmen added a comment -

        Anders, can we, in the CARGO Maven2 plugin, dynamically add a dependency from the Maven2 repository?

        The idea would be to add, based on the targeted JBoss version, thins from http://repository.jboss.org/maven2/org/jboss/integration/jboss-profileservice-spi/ ... another issue: these are not available on the Maven2 central repository!

        What do you suggest?

        Show
        Savas Ali Tokmen added a comment - Anders, can we, in the CARGO Maven2 plugin, dynamically add a dependency from the Maven2 repository? The idea would be to add, based on the targeted JBoss version, thins from http://repository.jboss.org/maven2/org/jboss/integration/jboss-profileservice-spi/ ... another issue: these are not available on the Maven2 central repository! What do you suggest?
        Hide
        Anders Hammar added a comment -

        It should be possible. Similar thing is done in the Sonar maven plugin IIRC:
        http://fisheye.codehaus.org/browse/mojo/tags/sonar-maven-plugin-1.0-beta-1

        Regarding the repo, we could do one of the following:
        A) dynamically add a hard-coded jboss repo
        B) Leave it to the user to have a repo with the jboss artifact defined

        B is the best option as we can't know for sure that the user has access to the JBoss repo (he/she could be, like I often am, running in a closed corporate environment with a repo manager).

        The jboss-profileservice-spi artifact exists in JBoss's new Nexus-hosted repo:
        https://repository.jboss.org/nexus/content/repositories/releases/

        Show
        Anders Hammar added a comment - It should be possible. Similar thing is done in the Sonar maven plugin IIRC: http://fisheye.codehaus.org/browse/mojo/tags/sonar-maven-plugin-1.0-beta-1 Regarding the repo, we could do one of the following: A) dynamically add a hard-coded jboss repo B) Leave it to the user to have a repo with the jboss artifact defined B is the best option as we can't know for sure that the user has access to the JBoss repo (he/she could be, like I often am, running in a closed corporate environment with a repo manager). The jboss-profileservice-spi artifact exists in JBoss's new Nexus-hosted repo: https://repository.jboss.org/nexus/content/repositories/releases/
        Hide
        Anders Hammar added a comment -

        After a moment of thinking, I figure there's another option instead of dynamically adding this artifact in the plugin. That would be to leave it to the user to specify this dependency in the cargo plugin configuration.

        The benefit of this would be if some other artifact, than the one we think, should be used. Mainly this would be the case if using JBoss EAP (JBoss licensed/supported version of the container). There will be a different, EAP-specific, repository with the correct artifact available soon. As a dynamically added dependency can't be removed through configuration (I think), such thing could be a problem for those of us using the EAP.
        The configuration would be a little bit cumbersome, but maybe we could start with this approach? The code would be simpler.

        Here's an example:
        http://www.sonatype.com/people/2008/04/how-to-override-a-plugins-dependency-in-maven/

        Show
        Anders Hammar added a comment - After a moment of thinking, I figure there's another option instead of dynamically adding this artifact in the plugin. That would be to leave it to the user to specify this dependency in the cargo plugin configuration. The benefit of this would be if some other artifact, than the one we think, should be used. Mainly this would be the case if using JBoss EAP (JBoss licensed/supported version of the container). There will be a different, EAP-specific, repository with the correct artifact available soon. As a dynamically added dependency can't be removed through configuration (I think), such thing could be a problem for those of us using the EAP. The configuration would be a little bit cumbersome, but maybe we could start with this approach? The code would be simpler. Here's an example: http://www.sonatype.com/people/2008/04/how-to-override-a-plugins-dependency-in-maven/
        Hide
        Savas Ali Tokmen added a comment -

        OK, so in this case the user needs to manually specify, when using the container, a <dependencies> section under <plugin>. That's OK for me.

        Do we impose the same for Java as well?

        IMO, it's understandeable as long as it is correctly documented.

        Show
        Savas Ali Tokmen added a comment - OK, so in this case the user needs to manually specify, when using the container, a <dependencies> section under <plugin>. That's OK for me. Do we impose the same for Java as well? IMO, it's understandeable as long as it is correctly documented.
        Hide
        Savas Ali Tokmen added a comment -

        Fixed rev. 2430.

        Documentation on: http://cargo.codehaus.org/JBoss+Remote+Deployer

        Happy testing

        Show
        Savas Ali Tokmen added a comment - Fixed rev. 2430. Documentation on: http://cargo.codehaus.org/JBoss+Remote+Deployer Happy testing
        Hide
        Anders Hammar added a comment -

        Regarding dependencies section for the plugin, yes that's how you do it.

        What do you mean "for Java"? Do you mean when using the Cargo API directly?

        I have some comments for r2430 that I'll post to dev list.

        Regarding the doc: Why would one need to define a dependency to cargo-core-tools-jboss-deployer-5.1-and-onwards? As that's within cargo I'd say we should handle that. Anything outside cargo (like jboss-profilesrvice-spi) could justify a user added dependency. What do you think?

        Show
        Anders Hammar added a comment - Regarding dependencies section for the plugin, yes that's how you do it. What do you mean "for Java"? Do you mean when using the Cargo API directly? I have some comments for r2430 that I'll post to dev list. Regarding the doc: Why would one need to define a dependency to cargo-core-tools-jboss-deployer-5.1-and-onwards? As that's within cargo I'd say we should handle that. Anything outside cargo (like jboss-profilesrvice-spi) could justify a user added dependency. What do you think?
        Hide
        Savas Ali Tokmen added a comment -

        Yes, by "Java" I mean the API directly.

        One needs to define a dependency to cargo-core-tools-jboss-deployer-5.1-and-onwards because it could also define a dependency to cargo-core-tools-jboss-deployer-5.0. That's because the API is not method-compatible between JBoss 5.0 / 5.1 and later.

        If you have a better solution, feel free to commit.

        Show
        Savas Ali Tokmen added a comment - Yes, by "Java" I mean the API directly. One needs to define a dependency to cargo-core-tools-jboss-deployer-5.1-and-onwards because it could also define a dependency to cargo-core-tools-jboss-deployer-5.0. That's because the API is not method-compatible between JBoss 5.0 / 5.1 and later. If you have a better solution, feel free to commit.

          People

          • Assignee:
            Savas Ali Tokmen
            Reporter:
            Marie
          • Votes:
            14 Vote for this issue
            Watchers:
            17 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: