A Sandbox provides a pre-configured development environment that you can run on your laptop computer. The VM version provides a Linux system on which to test the software you are developing in an environment close to what is used in production. Although the Sandbox was originally created for CAS, it can also be used for Shibboleth, Netid, or any other Java Web application.
The Sandbox incorporates a number of steps that a new developer would have to discover by trial and error. Does your Java have the unlimited cryptography files and does it have the Yale Certificate Authority files installed? Do you have both a current Maven and the old Maven 2.2.1 that Jenkins runs? There are a few changes required to the standalone.xml configuration file in JBoss, and you need the database drivers installed. Have all of the servers, drivers, JREs, and versions of Maven been configured to Eclipse?
Its not that you cannot solve each of these problems in a new environment. It just takes days or weeks. The Sandbox makes it all just work.
That's not how WE do it!
Of course Ubuntu is best, or maybe Red Hat, or maybe Windows, or maybe the Mac. Everything should go in /opt, or maybe /usr/local. Java 1.6 is stable, but you must have the new features in 1.7, and of course 1.8 is current. Tomcat is much simpler and do everything with Spring, or JBoss is standard and do everything with EJBs. The user interface must be JSP, JSTL, JSF, MVC, Struts, Velocity, ...
Even if you can get everyone in Yale ITS to agree on a choice, management will then hire some consultants or offshore the next project and a new group of developers will be absolutely sure they know all the answers. You can try to force everyone to use a single solution, but they will hate it and blame it when they make things end badly.
The Sandbox will be a failure if we try to force everyone to do things in exactly one way. The purpose of the Sandbox is to avoid developers wasting days or weeks reconfiguring their systems before they can start to be productive. It provides a set of tools, but more importantly it provides a strategy to use them in a way that makes sense without tripping anyone's religious sense of the "one true way" to work.
You need an operating system. Thanks to Java, the modern Sandbox is largely independent of operating system choice. You can run it on any Linux distribution or Windows. Someone will adapt it to Apple and contribute the result, but for now we assume it is like Linux. You need a Java, but the Sandbox does not care if you believe that the Oracle Java is best or you insist on open source. It doesn't matter what path Java or JBoss use on the production system. It doesn't matter what path the RPM or apt-get tool uses if you ask the system to install them. The Sandbox doesn't use the "standard" Java or JBoss or Eclipse that comes with your system. All the Java tools can be installed a second time, in a different place, with a different version and configuration. The Sandbox provides its own copies and versions of everything separate from what or where your system or distribution normally puts things.
It would be great if there was only one sandbox, but there are different executables for Linux and Windows, and differences in the line ends of text files. The safe choice is to have two Sandbox images for the two systems, but to put everything in exactly the same relative directory path on both images.So Java will be in /usr/java/jdk1.7.0_60/bin/java or \usr\java\jdk1.7.0_60\bin\java.exe. Because Java uses "/" and "\" interchangeably and assumes .exe on Windows executables, most configured paths work the same on both systems.
Java tools don't have installers and they generally don't change the registry. Of course, if you are installing something as a service to run automatically at boot time, then there is a required system configuration. However, in the Sandbox everything runs interactively from Eclipse. So the only configuration is Eclipse configuration.
To fully exercise every part of an application you may have to install optional libraries in the system. Nominally the Netid application requires the kadmin Kerberos library to run, but it exposes a parameter and if you install it with "kadm5_activation=false" then it doesn't use that library and can even run on Windows. When a particular system service is only marginally important and can be bypassed or mocked out, this is a best practice.
Shibboleth runs in production on JBoss 5, CAS on JBoss 6, and Netid on Tomcat 7. Shibboleth can run together with CAS on JBoss 6, but changing Shibboleth may be too much trouble. If more than one Web Server has to run on the same machine, then you need to dedicate different port numbers (or else bind each server exclusively to a particular virtual Ethernet adapter).
For development and debugging, it is simpler if you do not use SSL (unless you are actually testing SSL features like User Certificates).
Everything is configured around Eclipse. If you insist that IntelliJ is better, you can try to duplicate the configuration, but do it on your own time.
If a directory has to be configured in some property file, then it is probably to test that particular directory in the same location it would have in production. For example, there is a strong bias to actually put JBoss log files in /var/log/jbossas/standalone because you may have to explicitly configure the same path in your log4j config file. The Sandbox convention is therefore to create Windows directories with the same relative name as the Unix path and to keep them on the R: disk letter (therefore "R:\var\log\jbossas\standalone").
Because the Sandbox is not a production environment, it doesn't matter if it runs a bit slower. If the OpenJDK has a memory leak that crashes programs that have been up for a month, programs are restarted on the Sandbox every 10 minutes. You want a stable environment, because you want to be debugging problems in your application and not in the Java runtime. If you believe that VMWare runs faster than VirtualBox, that doesn't matter for the Sandbox. VirtualBox is chosen because it is easiest to use even if we would never run it in production, but if you insist you can run VMWare or Hyper-V.
Two "Disks"
The original sandbox was a single VM with a single disk. However, this mixed the operating system with the application development components. So the modern Sandbox is really a second disk image that contains only the Java, Eclipse, JBoss, Maven, and other tools separate from the system. You may be offered a particular OS to go along with it. Except for the virtual Network configuration, there will be little interesting in the OS piece and you may upgrade or replace it as you choose.
The second disk is labelled SandboxData, although it contains a lot of executables and very little in the way of actual data. There have to be separate versions for Windows and Linux, but they have the same directory structure and the same non-executable files.
Because Eclipse is on the SandboxData disk, it becomes the current directory and therefore the current disk in Windows. However, Eclipse unfortunately puts a fully qualified path in its internal configuration files that includes the disk letter even if you would prefer it be omitted. So we have to choose some letter, and we chose R: because it is in the middle of the alphabet and less likely to already be in use if you attach the SandboxData disk to your native Windows laptop operating system instead of to a virtual machine running under that system. It is possible, but rather annoying, to reconfigured Eclipse to change all the disk letter references.
Linux doesn't have disk letters, but there are several different "public" mount points for a second disk. Ubuntu likes to mount portable disks (USB drives) with a path like "/media/SandboxData", but Fedora prefers to follow a convention that implies a much more transient name of "/run/media/[username]/SandboxData". No matter where you mount the disk, you can create symlinks that cause the directories to appear to be anywhere.
However, the rule that the Sandbox is absolutely separate from the RPM or apt-get installed versions of the same program would prohibit configuring symlinks so /opt/eclipse points to /media/SandboxData/opt/eclipse. That could collide with the real OS install of Eclipse. So the Sandbox on linux needs a path that works on all systems, and /media/SandboxData seems to be a middle of the road choice. It implies a degree of impermanance (so you can eject one disk and mount a different one if you want to work on a different project) but also a degree of durability (so you can make symlinks to a specific path).
The Sandbox OS may be more current than the production system. Java applications don't care if they run on Windows or Linux, so they clearly don't care about the difference between Centos 7 and Fedora 22. You may find the lastest system features more convenient, or you may prefer the old version of the desktop and hate the changes in the latest version of Gnome.
The SandboxData disk, however, has to make old versions of Java and JBoss available because the applications really do care about those options. If you work on one application at a time, then you may have a SandboxData optimized for just that one application. However, development on CAS sometimes requires changes to Shibboleth and to Netid, and those three applications run on different versions of Java, and while CAS runs on JBoss 6, Shibboleth runs in production on JBoss 5 (although it can run on 6), and Netid requires Tomcat. So you may use a SandboxData disk with all of the versions needed by all of the systems.
The Sandbox system allows to to edit, compile, and debug the program. After debugging, the Sandbox commits source changes back to Subversion. To move those changes even into DEV requires a Jenkins Build job that checks the source out of Subversion, reruns the compile, and stores the JAR or WAR on the Artifactory server. So the only external consequences of the Sandbox development are the source changes in Subversion. Except for that, everything that happens in the Sandbox is private and doesn't matter.
Installation
VirtualBox is free, open source, quite easy to use, and available for all the host operating systems we use. Normally you install whatever is the current version from virtualbox.org. VirtualBox is an open source project, but Oracle also provides some proprietary extensions that you are prompted to install immediately after you install the base software.
You can decide later on to mount the SandboxData files natively on your Windows or Linux laptop. This should not be an initial choice because you may have to change some configuration parameters, and it is better to get used to the VM before you attempt an advanced configuration process.
The user named "casdev" is defined to each VM image. OK, so the Sandbox was originally created to develop CAS, but there is no reason to change the userid if you are working on IIQ instead.
If you launch the VirtualBox application you will see a management console. It displays the Virtual Machines (VMs) that you already have and provides a Wizard for creating new VMs, typically by running the OS installer CD image for Windows or a Linux distribution. If you ask it to start an existing VM, VirtualBox creates a simulation of a full personal computer and even runs a power up BIOS. It then boots from the virtual hard disk image or from the virtual CD image.
After installing a new OS, you can mount a virtual CD on the virtual machine and install Linux or Windows Guest VM device drivers. These drivers know about the VM environment, they provide more flexible screen management, and the ability to cut text in the host operating system and then paste it into an application running on the VM (or the reverse). VirtualBox is slowly working on the ability to drag and drop files between the host and the VMs.
A specific restriction on VirtualBox is that the files that it creates to represent the VM and its hard disk are configured with fully qualified path locations, and they contain references to LAN adapters and audio cards on the host machine. They cannot simply be copied from one place to another without fixing this configuration. You can edit the XML in the *.vbox XML file, or you can use the VM clone function to get VirtualBox to make a copy of the file in a new location, or you can Export and then Import the VM on another system.
The Sandbox is distributed as a Exported *.ova file. This is an open standard form of zip file that contains both the machine configuration and the disk image. It can be loaded into VirtualBox (or VMWare for that matter) to create the virtual machine. During installation, or any time before you start the VM, you may need to configure features that are potentially dependent on your local machine configuration. VirtualBox has a feature called "Shared Directory" that allows the host operating system to share one of its directories with the VM (like a network share, but implemented without the network). When the distribution was built, the shared directory was "D:\sandbox", but you may want to turn this off (it is a convenience) or change the host directory path, especially if you do not have a D: drive or are not running Windows on your host computer.
You may be asked to reconfigure things that you forgot to change when you start the VM for the first time. For example, on the computer that created the Sandbox there was a specific physical Ethernet adapter with a specific name assigned by Windows. Your computer will also have an Ethernet adapter, but it will have a different name. VirtualBox will ask you when it goes to replace the old name with the local name on your computer. If you only have one LAN adapter it hardly seems necessary, but in theory you could have two LAN adapters and then it would be important to choose the right one.
It is easy to go back and fix things, but do not rush to install the Sandbox image before you have read the rest of these instructions so you know what the configuration means.
casdev
There is one user named "casdev" with admin (sudo) privileges. You login, run Eclipse, and do all your development as this user. The /home/casdev directory holds the Eclipse workspace and all the casual files. Because JBoss is started from Eclipse, it also runs as casdev. Therefore, the JBoss and Eclipse directories are owned by casdev even though they are installed elsewhere in the file system.
The password for user casdev is not particularly secure, since it can only be used by the developer on the host machine. However, it will not be published here. Ask someone for it.
Where
Oracle Java comes in a standard Red Hat distribution format called an "RPM" that contains both the files and instructions where to put them. Oracle puts a JVM in /usr/local/java. Red Hat official RPMs for JBoss are not available without a subscription, and RPMs for Eclipse are typically several releases behind the current verison. So JBoss comes from http://jbossas.jboss.org/downloads.html and Eclipse comes from http://www.eclipse.org/downloads/ and they are unzipped into subdirectories of /opt.
Then ownership of the directories is assigned to the "casdev" user instead of "root". JBoss contains configuration files and it writes to work directories that are part of the single distribution directory tree, and Eclipse has to change itself whenever you add new software. Eclipse and JBoss could have been put in the casdev HOME directory, but putting them in /opt seems cleaner. They are not, after all, part of your normal development workfiles. The Eclipse workspace that you are using goes in the casdev home.
There are a few things that have to go in the same place in the Sandbox and production. For example, the log files should be written to /var/log/jbossas on the Sandbox because that is where they go in production and that specific path has to go into log4j.xml. The JBoss Server configuration in Eclipse is modified to add -Djboss.server.log.dir=... onto the end of the JBoss start command.
The VM
The VM is a standard Virtualbox 64 bit Linux configuration. With JBoss running the used memory only gos up to 1.3 GB, so the amount of virtual RAM for the VM could be reduced to 1.5 or 2 GB if you need to run two VMs on an 8G laptop.
The VirtualBox Guest Additions are a set of drivers for the VM operating systems. These mouse, keyboard, video, and filesystem drivers support the integration of the VM interactive environment with the host system. For Linux, the Guest Additions are distributed in source and are compiled and then linked into the system. The source of the Guest Additions changes when you get a new version of VirtualBox, and the Additions have to be recompiled and installed every time the Linux Kernel changes, which happens frequently after you apply normal weekly maintenance to the Linux system. If you have made a change that breaks the Guest Additions then the VM window shrinks to a fixed size and the mouse gets captured when you click in the window and can only be detached from the VM by pressing the right Ctrl key. When this happens, click the outside (VirtualBox) menu item Devices - Insert Guest Additions CD. Inside the VM window you get a popup asking if you want to autorun the software on the CD that was just inserted. Click the "Run" button and let the Guest Additions rebuild.
It is not generally possible to drag and drop files between the Linux and Windows systems. Of course, you can use network file sharing between the machines, but there is a simpler solution. VirtualBox provides a feature called "Shared Folder". In the settings for the VM, there is a section for Shared Folder. You can designate one or more directories on the host computer (D:\sandbox is configured initially for the Sandbox VM). This directory is then given a name ("sandbox" for D:\sandbox). The shared host folder appears to the VM to be a virtual disk or virtual shared disk that can be mounted in Linux or assigned a disk letter (if you have a Windows VM). For Linux VMs, the shared folder is automatically mounted (because of the check box in the VM settings) to the location /media/sf_[name] (that is, /media/sf_sandbox for the name "sandbox"). The casdev user has been added to a group that allows read/write access to the files in the shared folder. This allows easy transfer of files between the VM and the host (Windows?) operating system. Copy files to or from C:\sandbox on the one end, and to or from /media/sf_sandbox on the other end.
The Virtual Network
Each VM has a virtual LAN adapter. VirtualBox can be configured to support this virtual adapter in several different ways. This is the most complicated step in the Sandbox configuration and needs to be understood, at least in basic terms, so the developer knows how to interpret behavior.
First, we need to define a few network terms. Suppose you have several real computers that you are connecting together in a home network. If you wire them to each other through a switch but you do not connect them to any router, then you have a Private Network. The machines can talk to each other but not to the outside world. You can assign each machine a static IP address, and for home networks this is traditionally a 192.168.1.* number. Of course this is the most secure arrangement, but it is not very useful.
So you get a DSL connection from the phone company or a cable connection from you TV provider, and you connect it these days to a Wireless Router box. Home routers add two network functions: DHCP and NAT. DHCP assigns addresses (from the 192.168.1.* subnet) to machines that are not configured to use a specific private address. NAT allows the router to forward client requests from any computer on the private network to the internet, but it changes the IP address on each packet of data so that the outside world thinks the request came from the router itself. This is important because the phone or cable company only assigned one IP address to your home, and the router has to own and manage that address.
NAT works automatically when the home computer is a client and the server is out on the internet. To allow Internet machines to connect back to a computer in your home network, then you have to configure the "Port Mapping" feature of the router to direct all Internet requests for a particular port (example: 8080) to a particular home computer.
Your host computer may be a laptop connected to the Yale network, but the VMs that it runs under VirtualBox are typically unknown to Yale and you probably want them to be unavailable to other machines. So VirtualBox creates various virtual network solutions emulating different elements of the typical home network solution.
When you create a VM and give it a virtual LAN adapter, you can configure the connectivity of that adapter to use specific named options:
- NAT - One VM appears to be connected to its own network with a NAT router simulated on the host real machine. Client programs on the VM can access the Yale network and Internet, but neither the host computer nor the other VMs can talk to that VM except through ports mapped from the VM to the host computer. If you map ports, they become visible to the outside world.
- NAT Network - Several VMs are connected to a private network with a NAT router simulated on the host real machine. Like the previous configuration, except in this case the VMs can talk to each other as if they were real computers on a real network, but the host computer still can't talk to them.
- Bridge - All the VMs appear to be directly connected to the real network to which the host computer is connected. At Yale, that means that every VM has to be assigned its own IP address from Data Network Operations. Since that address is real, no other developer can use the same set of addresses for his Sandbox machines. This also exposes the VMs to the outside world (at least the Yale network). This option is useless for a sandbox.
- Host-Only Adapter - First, this creates a virtual LAN adapter on the host computer (you get a dialog box on Windows asking you to install a new device). Then logically it connects this simulated LAN adapter to a Private Network to which all the VMs are connected. Typically you assign a static address like 192.168.137.1 to the host computer and then other static addresses like 192.168.137.10 to each VM. VirtualBox does not provide any NAT router function, so this private network is isolated from the real network.
Now for Sandbox requirements: The VMs have to be able to communicate with each other just like real machines, so they can test various clustering options. The VMs have to access servers in the Yale Network (SVN for example to update or commit source changes). For security, other machines must not be able to access the VMs. It is useful, but not an absolute requirement, for the host computer to be able to connect to port 8080 (JBoss) on the VM.
It is possible to meet all these requirements with a Host-Only adapter and an exotic system configuration or third party software on the host computer. However, the simplest solution is to recognize that while one virtual LAN adapter cannot do all these things, two different adapters can provide complete coverage.
One adapter (that VirtualBox refers to as LAN Adapter 2 and Centos chooses to name "enp0s8") uses a simple "NAT" connection to give VM clients access to the Yale network (SVN) and to the Internet (the Centos software update sites). You map no ports, so this provides only outbound service. It is automatically assigned a meaningless IP address that doesn't matter because no other computer can talk to it.
The other adapter (that VirtualBox refers to as LAN Adapter 1 and Centos chooses to name "enp0s3") is a Host-Only Adapter that creates a simulated Private Network that connects the VMs to each other and to the Host computer. It is not connected, routed, or bridged to Yale or the Internet, so it cannot be used to access other machines and no computer other than the host or the VMs can use it. The host and VMs are assigned static 192.168.*.* addresses to talk to each other just like real computers connected to a regular private home network. Since these addresses are not typically available
NAT is part of VirtualBox and requires no configuration. However, a Host-Only network has to be set up before any VM can use it. In the VirtualBox management console (that lists the installed virtual machines). Click File - Preferences - Network. Select the Host-only Networks tab. If no network is listed, click the Add 
button to create one. It will be called "VirtualBox Host-Only Ethernet Adapter" and when you create it you have to let your real laptop operating system add a new device. If you double click the now listed adapter, you can set its IPv4 Address to 192.168.137.1 and the Network mask to 255.255.255.0. It does not need a DHCP server because static addresses are configured in the VMs.
If you run Windows as the host computer, there is one additional cleanup step. When VirtualBox create a new simulated LAN Adapter in the Windows system, it left all the default configuration options. Go to Control Panel - Netowrk and Internet - Network Connections. Right click the VirtualBox Host-Only Network connection and choose Properties. DoubleClick the "Internet Protocol Version 4" item in the list box. Click the Advanced... button, choose the DNS tab, and turn off the checkbox at the bottom for "Register this connection's addresses in DNS". If you do not do this, then when you login to the Yale AD, your Windows desktop tries to register the 192.168.137.1 private address on this adapter with the dynamic DNS service that AD maintains. It probably will not cause a problem, but if another computer at Yale (frequently another machine you own) also has a private virtual network mapped to 192.168.137.* then from that DNS name that computer can believe that your computer is a VM on its private network, and then become unable to communicate with your machine because the two private networks are not connected. You can spend hours trying to figure out why you cannot share files or start a remote desktop session before you realize that your network traffic is going into the private network black hole instead of transiting the real network.
The Sandbox VM comes configured with two virtual LAN adapters (NAT and Host-Only). The Sandbox OS is configured with three adapters (NAT and two alternate versions of Host-Only to easily configure two VMs from one system image). It uses the NAT adapter to get to the outside world. You configure one of two Ethernet hardware (MAC) addresses with the VirtualBox console, and which hardware address comes up tells the Sandbox if it is the vm-ssoboxapp-01 host with private IP address 192.168.137.10, or the "-02" host with IP address ending in ".11".
The open format distribution file (the *.ova file you install the Sandbox VM with) sort of knows that there are supposed to be two virtual LAN adapters and it sort of knows that one is to be NAT and one is to be Host-Only. There is an obvious conflict between an "open format" file that can be read by VirtualBox or VMware and configuration options like "Host-Only" that may be a VirtualBox technical term that other vendors name differently. So when you install the *.ova file, VirtualBox displays the proposed hardware configuration and gives you a chance to explicitly connect any dangling configuration items to specific local chocices. For example, if you did not follow the previous instructions and did not create the Host-Only adapter on the host computer, then there would be no Host-Only adapter to connect the Sandbox VM to, and then one of the two LAN adapters is left with nothing it can connect to. If you do not fix the configuration problem at the start of installation, you can always fix it later before you start the VM.
If you need to simulate a second VM, clone the Sandbox computer (as explained below) and then in the clone configuration you leave Adapter 1 attached to the same Host-only Adapter but now you expose the Advanced options and change the MAC Address to be one larger (change AD at the end to AE).
The Centos operating system in the Sandbox VM has two different configurations for two different LAN adapters with different MAC addresses. It selects which IP address it uses based on which MAC address the simulated LAN adapter exposes. The first VM (ending in AD) gets 192.168.137.10 and the second (AE) gets .11. However, it is not possible to automatically change the hostname based simply on the MAC address. You have to do that manually the first time you boot up the cloned second VM. Issue the following command once:
sudo hostnamectl set-hostname vm-ssoboxapp-02.web.yale.internal
to change the hostname permanently on that VM.
However, while each machine has to know its own name, it also has to be able to locate the other machine in the "cluster". In production this is accomplished through the DNS server. Fortunately, all systems support a simple static alternative called a "hosts" file. This file is /etc/hosts on Linux or Mac, and C:\windows\system32\drivers\etc\hosts on Windows. It is a simple text file where each line starts with an IP address and then contains one or more host names associated with that address. The VM has a hosts file with two lines:
192.168.137.10 vm-ssoboxapp-01.web.yale.internal casvm1
192.168.137.11 vm-ssoboxapp-02.web.yale.internal casvm2
This maps the full name and a shorter nickname (casvmx) that is easier to type. You should add these lines to the "hosts" file on your host (Windows or Mac) computer so that you can access the VMs by name through the Host-Only adapter.
CAS currently has only two VMs. If that changes, or you want to use the Sandbox to work with a different product that has a different cluster configuration with more machines, then you can follow the cookie cutter instructions and add additional Network adapter configurations in /etc/sysconfig/network-scripts and add an extra line to all the hosts files.
Centos 7 has a Firewall service (firewalld) that, like the Windows firewall service, provides some protection to a desktop or server machine. It is not used in production machines behind the corporate firewall, and similarly it is not useful on VMs that are hidden on the Host-Only private virtual network, so that service is disabled in the Sandbox. It you want to turn it back on, you have to configure it for JBoss and the clustering.
Clone
The Sandbox VM can be cloned to produce a second CAS VM for testing cluster failover.
Cloning is a VirtualBox operation performed on the VirtualBox control window. Select the machine and choose Clone from the Machine menu. There are two kinds of Clones:
A Full Clone makes a complete copy of the VM configuration and the hard disk. This is the simplest option, but it takes a few minutes to make a second copy of the hard drive file
A Linked Clone is much faster and smaller. It creates a "snapshot" of the current hard drive file (an image of the disk that does not change and can be shared between the original VM and the Clone. Then the two VMs each get a new file that holds only the changes made to the hard disk since the snapshot was taken. Once the snapshot is taken, any files that are changed, for example changes to the source files in the Eclipse workspace, are separate on the original and clone VM and so they have to be copied from one to the other. You can commit changes to SVN and then update the files on the other VM, but after a while that gets to be annoying. If you make a lot of changes, do it on the original VM, discard the old clone and make a new one. It only takes a few seconds to create a Linked Clone.
After you delete a Linked Clone you may want to take a few seconds more and delete the disk snapshot that was created for it. That merges the changes back into a single disk image file.
There are two steps that you must perform after you create the Clone to distinguish it on the network from the original VM. Before you start the Clone VM, edit the Settings - Network - Advanced - MAC address changing the last byte of the address by adding 1 (change the "AD" at the end to "AE"). Then after the clone starts up for the first time, issue the command "sudo hostnamectl set-hostname vm-ssoboxapp-02.web.yale.internal" to change the hostname. After you do this a few times it will become routine and deleting the old Clone, creating a new one, updating the MAC address, and changing the hostname will take only a few minutes and is much simpler and faster than copying files from one machine to the other.
CAS Development
CAS development is the same whether you are working on a Windows host computer (with Eclipse and JBoss) or on the Sandbox VM. You edit in Eclipse, build with Maven, and run JBoss from the Eclipse toolbar. Generic CAS develpment is described elsewhere. This section just describes the Sandbox.
When you get a new copy of the Sanbox VM, the casdev user will have an Eclipse workspace in its home directory. This will have a project for the CAS source and for the CAS installer. However, the project may have old files. So the first step is to synchronize the workspace with the SVN server and update the files with whatever is current.
If you are starting work on a whole new release of CAS, then delete the old project and create a new project using the instructions provided in CAS Development Conventions at Yale.
There are two configured Maven "jobs" in the Eclipse Run - Run Configurations...
If you click the dropdown mark (V) behind the Run icon on the toolbar (a green circle with a right pointing triangle) then there is a CAS Build job (which runs the Maven POM in the CAS parent directory to compile everything and build the CAS WAR) and a CAS Install job (which copies the CAS WAR to the JBoss deploy directory and inserts parameters into the configuration files). Run the Build first, then the Install.
Elsewhere on the toolbar there are JBoss Run and Debug icons (a green arrow pointing right and a bug with an arrow under it). They can be used to start JBoss normally or with interactive debugging using Eclipse.
Changing the Sandbox
The Sandbox is separate from the contents of the projects in the workspace or the SVN. You could use the same Sanbox to develop with CAS 3.5.3 or CAS 4.0, and you could probably use it to develop any JBoss hosted application including Shibboleth.
Updating Centos 7 with newer versions of software or changing system configuration options is just standard Linux system administration.
Therefore, changing the Sandbox means installing a different version of Java, JBoss, or Eclipse.
You can install any version of Java using the Oracle RPMs. They go automatically into /usr/java. Generally you configure different versions of Java into Eclipse (Preferences - Java - Java Runtime) and then you select the verison of Java you want to target as a parameter of the Eclipse project, or as a parameter of the CAS Build and CAS Install Run configurations, or as a parameter of the JBoss Server runtime configuration. If you want to change the default version of Java that you get at the command prompt, Google for information on the Linux "alternatives" command.
There are separate instructions in this set of documentation for starting with a vanilla version of Eclipse and then adding the Subversive and JBoss Tools components, so they will not be repeated here.
To install a new version of JBoss, get it from jboss.org and unzip it into a new directory in /opt/jboss. JBoss Tools will configure it automatically if you ask. In Eclipse, go to Preferences - JBoss Tools, JBoss Runtime Detection. Click Search ... and have it search /opt/jboss. It will notice the new server and configure it. To change the default configuration, you need to display the Servers (Window - Show View - Servers). The Servers tab lists all the configured servers. Double click on the name of the server you want to configure. Click the "Open launch configuration" link for detailed startup configuration. In particular, you may want to allow browsers on other machines (actually only on the host computer) to access http://vm-ssoboxapp-01/cas by binding JBoss to the LAN adapter instead of just the local loopback. In the command parameters, change "-b localhost" to "-b 0.0.0.0". Also add a parameter to change the log directory "-Djboss.server.log.dir=/var/log/jbossas/standalone". If in doubt, compare this to the configuration of another JBoss server.
Disclaimer: configuring modern versions of JBoss AS 7, JBoss EAP 6.x, and Wildfly 8.x are all fairly similar. If you want to configure an older JBoss 5, that changes the entire directory structure and conventions and may require extra research.