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 errorThe default user is, however, named "casdev".
If you do not use the Sandbox, you can eventually stumble by trial and error to a workable development environment of your own. Along the way you will have to solve many problems. 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? Do you have Oracle and SQL Server database drivers installed in JBoss? How do you get JBoss logs to go to /var/log/jbossas/standalone instead of the log directory inside JBoss itself? You can duplicate the Server environment of the DEV VM, but that configuration is not designed for edit, compile, and debug. Before you get to DEV, you need something more friendly to developers.The solutions are not hard, but there are enough problems that crop up that you could spend days or weeks recreating the Sandbox environment, and that is just a waste of timeNone of these is a big problem, but these are just randomly chosen examples of the hundreds of small configuration issues you have to address.
The Sandbox is a friendly environment for developers to edit, compile, build, and debug the application. It is specifically not designed to duplicate the runtime configuration of production. For that you have DEV and TEST.
That's not how
...
I 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 I am not going to waste your time arguing that the Sandbox is the correct way to configure a development system. Everyone has their own opinions, and those who know least about things are sure that their ideas are somehow objectively correct. The Sandbox is therefore a concept and convention rather than any single fixed package. If you insist you can use Ubuntu, Fedora, Centos, Windows, or even Mac as the runtime operating system. In order to accommodate any application, it must be possible to run Java 1.6, 1.7, or 1.8 and any version of JBoss or Tomcat. Applications also can use Spring and any user interface framework.
However, after you struggle to get your first development environment just right, you will be assigned a second application, and then a third. Eventually you will tire of rearranging things to be exactly the way you like them on each new project.
So the Sandbox concept is flexible. If we try to force everyone to use a single solutionapproach, but then 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 thingsall their problems on the tool. Better to let them exhaust themselves making meaningless adjustments and then learn eventually that "good enough" is good enough.
Thanks to Java, you can develop CAS on Windows, then run it on Linux without a problem. Therefore the choice of the OS is only an issue if the application requires a particular library or interface that isn't available on specific systems. GSSAPI, for example, behaves differently on Windows and Linux even though it is a standard Java API.
Different Linux distributions put Java or JBoss or Eclipse in different places, and they may install different versions. Fortunately, the Sandbox must provide exactly the same version of Java that the application is designed to run under, no matter what version of Java a distribution wants to install. That means that the Sandbox provides its own copy of Java, Eclipse, and JBoss separate from any version of the same programs that you installed with an RPM or apt-get. Since this "second copy" of everything has to go in an arbitrary location, we are freed from any dispute about the one true correct place to put things in Linux.
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 set of Sandbox files for all operating systems. Unfortunately, Eclipse tends to automatically insert a disk letter into some of its configuration data when it is run on Windows. So an Eclipse Workspace has to be reconfigured when you move it between Linux and Windows. In addition, executable programs like java and javac are different on different systems (and different between 32 bit and 64 bit versions of the same system). So the Sandbox has identical directory structures and equivalent configurations, but there is generally a Windows version separate from the Java version.
The default operating system version of Java can be installed with a Setup on Windows or an RPM, but every other version of Java is just unzipped into a directory. If you want to run JBoss or Tomcat as a service then that requires some operating system configuration, but a Sandbox developer runs them interactively from Eclipse. This of course means that everything runs under a single userid (casdev) and all the files are owned by that user instead of some system userid. File security restrictions can be debugged when you move to DEV.
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.
...
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 Some applications have a custom log4j.xml or Spring configuration XML that references a cache directory or a file path explicitly. In this one type of case it is probably better 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 arrange the operating system and Sandbox so that the same file path can be used in development and production. Therefore, no matter what version of the OS you use, you will need to make "/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-Vstandalone" (or R:\var\log\jbossas\standalone in Windows) writable, and maybe owned, by the casdev userid.
Sandbox is not Production
The Sandbox does not have to run at maximum efficiency. It will not be up 24x7 for months, so rock solid reliability and stability are not a requirement.
Therefore, you have more flexibility choosing a VM host, Guest OS, Java runtime, and version of JBoss.
For example, while a particular application will be designed to run in a particular version of Java (1.6, 1.7, or 1.8) it doesn't matter for development if you are using OpenJDK or the Sun JVM. At various times in the past, the OpenJDK has a bad reputation for slow memory leaks that are a long term problem in production, but in development they don't matter.
While production services for some reason refuses to put routine maintenance on their VMs, the Sandbox is typically kept up to date with the latest bug fixes.
We would never run VirtualBox as a production hypervisor, but it is perfectly adequate for development. Of course, you are free to run Hyper-V if it is already installed on your laptop.
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.
...