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

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>

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).

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.

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.

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?

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.

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.

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.

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.

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.

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 ?

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

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-$

.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("/"))

else

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

}

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

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

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 ...

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)

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.

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.

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

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

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

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 : $

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

</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

Hello Cédric

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

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

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.

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.

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

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

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".

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]

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.

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

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.

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?

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/

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/

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.

Fixed rev. 2430.

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

Happy testing

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?

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.