...
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!
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 The Sandbox does not try to run the best operating system. It does not put applications in the correct directories. The problem is that no two people have the same opinion about how to arrange a system. The Sandbox provides a good default for the large number of people who don't care, but it allows you to do as much customization as you insist on doing. 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 approach, then they will hate it and blame all 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 LinuxNo matter what version of Java or JBoss you prefer, you have to run the release that the application uses in production.
A separate copy of the Sandbox may have been archived by the last person who worked with a particular application. If you pick it up and use it as is, then you can get right into development. If you only have a few changes to make, you can be done before you would have had a chance to make any system configurations.
However, if you feel strongly about KDE or Gnome or the version of Eclipse that was released last week, then an alternative is to keep your own personal optimized system disk. Then you only swap the SandboxData disk that contains the application, workspace, and JBoss. Because every SandboxData disk contains the same directories in the same places, the OS disk can have symlinks to the various components that remain valid even when you change disks. It is conventions like this that make the Sandbox a concept and strategy rather than a single image.
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.
Ubuntu and Red Hat put the same component or application in different directories, and if you go to the original developer you will get an entirely different layout. Different applications at Yale run on different releases of Java, and it makes no sense to change the default version of Java in the system let alone care what directory Java is installed into. So the SanboxData disk contains its own versions of Java. When you start Eclipse, the version of Java can be selected by the eclipse.ini file in the Eclipse directory. Then once Eclipse is running it has one or more Java Runtimes configured both as to version and location on disk. Because the Sandbox developer starts Eclipse and never leaves it, the location and identity of the default Java on the OS disk doesn't matter.
When you work in the Sandbox you work with a "second copy" of Java, JBoss, Tomcat, or Eclipse completely separate from any version of the same system you have installed with a package manager into the OS directories. This means that the Sandbox is independent of any controversy about where things go. No matter where you think applications should normally be installed, the Sandbox puts its stuff someplace else. That means, however, that you can switch from one application to the next seamlessly.
In production, applications run under a Tomcat or JBoss that has been installed as a service and is started (and configured) from /etc or the Windows Registry. In the Sandbox everything is run from Eclipse, and everything is configured in Eclipse and in the Workspace. The Sandbox makes no changes to /etc or the Registry. Of course, this means that JBoss, Tomcat, and the applications all run interactively under the default userid (casdev). This means that casdev has to Casdev must have write access to any directories used by the application, typically because it has been made the owner of those directories. If you need to validate file access security rules for the userid that runs jboss in production, you have to wait for DEV to test such chingsverify that things work with normal directory ownership rules, wait until you get to DEV.
It would be great if there was only one 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 configures the path to JAR libraries 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 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 fixesfor applications that run for weeks without being restarted in production. OpenJDK is fine for debugging a program that you restart every few minutes.
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.
...