|
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 add property: Other changes:
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 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-${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(), } 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 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 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. |
|||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
JMX deployer currently uses the same path on the local filesystem and on the server one
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>