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. 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. Most importantly, you can install your Java and your Eclipse anywhere you want, using any RPM or installer you choose, and the Sandbox doesn't care because no matter what choice you made for the system, the Sandbox doesn't use the java or Eclipse you installed in the OS. It supplies its own second copy, and even people with very strong view about where things should go on their system don't care where a second unofficial copy of the same thing goes.
Java development uses tools written in Java, and Java is system independent. A particular Java runtime is built for a particular operating system environment because it comes with executables (java, javac) that have to be built for that OS. You can have more than one Java runtime (JRE) on your computer, and even if one of them has been installed in a system library and has been designated as the default for that system, everything in the Sandbox is by default configured to use a different JRE in the Sandbox itself and ignore the system default. In the past, the OpenJDK version of Java has had bugs, and it is generally still not recommended for production. However, for debugging the JRE probably doesn't matter (although it must match the version number under which the application will run).
Java tools don't have installers. The most important tool is Eclipse, and it is just unzipped into any directory. Then you configure everything to Eclipse. You tell it which Java runtime to use for each application or function. You configure each version of Maven, each version of JBoss. When using the Sandbox, you start Eclipse and never leave it. Everything runs under Eclipse and so operating system environments and Paths do not matter. Therefore, the Sandbox does not depend on the OS configuration.
You do need to install into the OS any services or libraries that the application requires to execute. 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.
More than one Web Server may be available. 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 Ethernet address).
Although all these applications run https:// in production, it is much easier to debug if you can run them on plain http. CAS has a parameter "cas.cookie.secure=false" that turns off the flag that requires SSL before the Cookie is written, and again this is probably a best practice for development.
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.
Generally speaking, everything in the Sandbox is not in the location where it would normally go in production, and generally all these directories are owned by a single development userid. The exception to this rule are directories that have to be configured in the application to point to a specific path. For example, if your log files in production have to go to /var/log/jbossas/standalone and that specific location has to be configured in several different places, then it is probably safest to use the production location for that one purpose. In Windows you can use the same configuration, although it means \var\log\jbossas\standalone on whatever the current disk letter happens to be (R: is the Sandbox convention).
The Sandbox is not, by definition, a production environment. So it generally doesn't require efficient execution. If the OpenJDK has a history of memory leaks in applications that run for months without being restarted, the server in the sandbox will get restarted several times an hour. If you run the Sandbox in a VM, it doesn't matter if you choose VirtualBox, or VMWare player, or Hyper-V to serve as the host. We are developing business applications here, and they don't depend on having 3D acceleration in the video driver or a paravirtualized LAN adapter.
Of course the simplest thing to do is to accept the defaults and all our design decisions and treat the Sandbox VM as a utility device. You pick it up, you use it, and you don't confuse working to change the Sandbox with actually getting real work done. If that isn't good enough, then try to understand the design so you leave behind something others can pick up and use.
Two "Disks"
Originally the Sandbox was a single VM image on a single disk. That package binds the decisions that are important to the application under development (Java 1.7, JBoss EAP 6.2) with decisions that only matter to the user (Eclipse 4.4 or 4.5) and with choices of system (Fedora, CentOS, Ubuntu, or even Windows 10) that generate far more heated discussion than is helpful.
The solution was to create two separate virtual hard disks. One disk holds the system you have chosen to use (which mostly doesn't matter). The other holds some Java runtimes, Eclipses, some Mavens, some JDBC drivers, some JBoss or Tomcat instances, and some starter Eclipse workspaces.
Ideally the two would be independent. However, there are a few executables that are different in Windows and Linux, so the Java Runtime, Eclipse, and JBoss are either Linux or Windows and there have to be separate versions of the development disk for the two platforms. The format of these two disks is identical (same directories, same contents, just different executables).
In Windows the second disk is mounted as the R: disk. In Linux it is mounted in the same way that Linux likes to mount portable disks or thumb drives (as /media/SandboxData).
There is almost no specialized configuration on any operating system. This paper will provide suggestions for configuring the virtual network that are useful guidelines for development, simple debugging, and complex debugging. However, you can use almost any version of any operating system as long as machines that run the IDE (Eclipse) have a GUI and desktop.
This also means that you can customize your OS to be exactly what you want, then use it with different SandboxData disks to do development on different applications (or you can put all the applications on the same SandboxData disk and run them all together).
Sandbox systems tend to be kept more up to date than production systems. If you really want to try something new out while working, it is not unreasonable to work with a stable Beta of the next release of the OS. Having the latest features at hand can be useful.
The SandboxData disks, however, tend to lag behind because they have to match an environment that is already in production. So you will find Java 7 instead of 8, or JBoss EAP 6.2 instead of Wildfly 9.
The Sandbox allows you to edit and debug source. You can change existing files and create new files. You can work with Java source or configuration files. After you are done with basic testing, the changes you make are committed back to the Yale Subversion server. Then they are then used by the Jenkins jobs to build the DEV, TEST, or PROD environment.
So the result of Sandbox development is reflected in changes to SVN. After code goes into production, you can keep your copy of the Sandbox around for further development, or you can discard it and start over again with a fresh new Sandbox in any future project. If you have strong feelings about Linux or Eclipse, you may choose to customize your Sandbox VM to your preferences, and then it makes sense to save it and use it for other development, even for other software projects.
Installation
You need a current version of VirtualBox which you can get from Oracle (virtualbox.org). You can install it on a Windows or Mac desktop or laptop computer which becomes the "host". VirtualBox is an open source project, but Oracle also creates some proprietary extensions that you are prompted to install immediately after you install the base software.
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.
The VM displays on the host computer screen as an application window. However, this "application" thinks that it is an OS on a real computer. To make it behave seamlessly on the host monitor, VirtualBox provides some device drivers that you can install on Windows (or build and install on Linux). With the drivers the mouse can move smoothly into and out of the VM window, and cut and paste of text operates between VM applications and host applications.
Once installed, the VM will be a directory of files in the location VirtualBox is configured to store its VMs. This VM is configured by the installation process with specific locations on the host disk and the names of specific configuration features from that specific host. So you to install the VM on another computer, you have to "Export" it to a type of file that is not bound to one specific system.
The Sandbox is distributed as a *.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.