Neosavvy, Inc Modern Knowledge Blog

Continuous Integration with Jetty/Cargo/Maven/Bamboo

Recently I have had the pleasure of helping migrate a client to a maven build process where they wanted to also migrate to a Jetty container from a full blown JBoss application server. The decision to move to Jetty is probably wise as they don’t need all of the extras provided by JBoss as they aren’t really using all of them.

Regardless this move presented an interesting hurdle. One of the requirements that dictated success of the migration was successful remote deployment from a Bamboo continuous integration build environment on a windows server to a remotely deployed Jetty instance. The main crux of this setup is that Jetty does not support remote deployment natively. Also I chose to configure cargo’s remote deployer to handle the deployment in a push fashion. Luckily a kind person at Redhat has written a cargo remote deployer that can be deployed as a war file to the Jetty server. This deployer then allows the cargo maven plugin to push a file. The cargo hook however does not support the removal of the previously deployed artifact, so in a continuous integration environment trying to support a push button deploy won’t work – one has to cleanup after themselves.

Out solution was to use some functionality from JCSH to make a java client that can call a script on the Jetty server to delete the old artifact and restart the application server. The code to handle the remote call can be seen below and is admittedly hackish but definitely solved my problem in a few hours where I wasn’t necessarily granted the permission of infinite time to solve this problem.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77

import com.jcraft.jsch.Channel;
import com.jcraft.jsch.JSch;
import com.jcraft.jsch.Session;
import com.jcraft.jsch.UserInfo;
 
import java.io.*;
 
public class RebootJetty {
 
    private static String DISC_STRING = "###### SERVER CLEANED #####";
 
 
    private static String TEST_QA = "10.0.0.1";
    private static String TEST_QA_PASSWORD = "password!";
 
    private static String APP_QA_1 = "10.0.0.2"; 
    private static String APP_QA_1_PASSWORD = "password2";
 
    public static void main(String[] args) throws Exception {
        com.jcraft.jsch.JSch jsh = new JSch();
 
        Session testSession = jsh.getSession("root", APP_QA_1 , 22);
        testSession.setConfig("StrictHostKeyChecking", "no");
        testSession.setUserInfo(new MyUserInfo());
        testSession.connect(10000);
 
        Channel channel = testSession.openChannel("shell");
        channel.setInputStream(new StringBufferInputStream("/root/cleanupJetty.sh\n"));
        channel.connect();
 
        PipedOutputStream pos = new PipedOutputStream();
        channel.setOutputStream(pos);
        PipedInputStream pis = new PipedInputStream(pos);
 
        BufferedReader r = new BufferedReader(new InputStreamReader(pis));
        String s = "";
        while (s != null) {
            s = r.readLine();
            System.out.println(s);
            if (s != null && s.indexOf(DISC_STRING) > -1) {
                channel.disconnect();
                System.exit(0);
            }
        }
 
        System.exit(1);
 
    }
 
    public static class MyUserInfo implements UserInfo {
 
        public String getPassphrase() {
            return APP_QA_1_PASSWORD;
        }
 
        public String getPassword() {
            return APP_QA_1_PASSWORD;
        }
 
        public boolean promptPassphrase(String arg0) {
            return false;
        }
 
        public boolean promptPassword(String arg0) {
            return true;
        }
 
        public boolean promptYesNo(String arg0) {
            return false;
        }
 
        public void showMessage(String arg0) {
 
        }
 
    }
}

The Maven Cargo Plugin however was extremely helpful and was not extremely hard to configure however it doesn’t support all features equivalently in all application servers. Make sure to check your application server on their feature matrix for the scenario you are attempting to see if it even works out of the box. In my case they even advertise that it works, but after reading their Jira issues I noticed it is fixed in an alpha release of their plugin but advertised as working in their latest release…frustrating…

Cargo Feature Matrix for Jetty 6.x: http://cargo.codehaus.org/Jetty+6.x

You will need to make sure to download and build the war file to deploy to your target Jetty to support remote deployment. I found it here: http://svn.codehaus.org/cargo/resources/trunk/jetty-deployer/

To make the code above work I downloaded their entire trunk and built it locally, then I modified their war file to remove security settings so I wouldn’t have to setup a security realm in Jetty. Not sure how hard that really is, but given this is an internal continuous integration server I didn’t really care about deployment security as Bamboo would only allow secure uses to click the button to cause the deployment to occur. Other than that one of the 8 developers on the team would have to execute the maven profile to cause a deployment, and likely if one of them does it, then it probably needed to happen. Specifically the code I commented out was in here: http://svn.codehaus.org/cargo/resources/trunk/jetty-deployer/src/main/webapp/WEB-INF/web.xml I removed the login-constraint and the security-constraint.

Here is the code required to push a release to a remote running server instance. Just throw this in a profile in your pom or add the plugin to your build section if you prefer it run in your pom. I opted to use a profile so that I can enable it as necessary and others can use this same pom to build the WAR for normal use. There is another profile in use for a local deployment to Jetty which is way easier with cargo.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

        <profile>
            <id>deploy-to-qa</id>
            <build>
                <plugins>
 
                    <plugin>
                        <groupId>org.codehaus.cargo</groupId>
                        <artifactId>cargo-maven2-plugin</artifactId>
                        <version>1.0.1-alpha-1</version>
 
                        <configuration>
                            <container>
                                <containerId>jetty6x</containerId>
                                <type>remote</type>
                                <timeout>120000</timeout>
                            </container>
 
                            <configuration>
                                <type>runtime</type>
                                <properties>
                                    <cargo.hostname>172.1.0.1</cargo.hostname>
                                    <cargo.servlet.port>80</cargo.servlet.port>
                                    <cargo.remote.username>user</cargo.remote.username>
                                    <cargo.remote.password>pass</cargo.remote.password>
                                </properties>
                            </configuration>
 
                            <deployer>
                                <type>remote</type>
                                <deployables>
                                    <deployable>
                                        <groupId>${project.groupId}</groupId>
                                        <artifactId>${project.artifactId}</artifactId>
                                        <type>war</type>
                                    </deployable>
                                </deployables>
                            </deployer>
                        </configuration>
 
                    </plugin>
 
                </plugins>
            </build>
        </profile>

The final piece to the puzzle is likely the cleanupJetty.sh script that resides on the target server. This script simply stops jetty, deletes the war file deployed by cargo, then starts jetty again. It is called via a call into the JSCH program above from the windows box via command line (in Bamboo) and then after it completes it kicks off the maven build. Here is the contents of the script:

1
2
3
4
5
6

#!/bin/bash
/opt/jetty/bin/jetty.sh stop
rm -rf /opt/jetty/webapps/NAME_OF_WAR
/opt/jetty/bin/jetty.sh start
sleep 20s
echo "###### SERVER CLEANED #####"

I sure hope this little tidbit helps someone out there as I did a lot of reading on forums and Jira bugs to figure out how to make this all work. If you have a similar setup please let me know as I am happy to help you out. Also please note that I will openly admit that the JCSH hook from a windows box into the bash script could arguably be considered a hack, but sometimes it just has to work.