...
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 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.
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 timeIn 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 have write access to any directories used by the application. 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 chings.
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 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.
There may be a different Sandbox for every application, or there may be a Sandbox that combines applications. For example, the Expired Password function runs partly in CAS (on JBoss) and partly in the Netid application (on Tomcat). If you need to test both, then with enough memory you can run two JVMs, but you can also install both JBoss and Tomcat and have both applications in the same Eclipse workspace. Of course, to run both JBoss and Tomcat on the same machine means that only one can be configured to use port 8080 and the other must be configured to a different port number.
Typically applications are debugged without SSL even if they run SSL in production.
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 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" (or R:\var\log\jbossas\standalone in Windows) writable, and maybe owned, by the casdev userid.
...
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 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.
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.
Two "Disks"
The core of the Sandbox is a separate disk image (named "SandboxData") that contains 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 referencesdatabase drivers, and so on. This disk can be cloned or checkpointed so it can be shared between multiple virtual machines, even with different Linux distributions.
There will generally be a VM and a system disk that comes with a particular Sandbox instance, but it it comes with Fedora and you prefer Ubuntu, then switching the OS generally requires just a small amount of network reconfiguration.
There is a different version of SandboxData for Windows and Linux. Eclipse saves disk letters when it configures directly locations on Windows. Therefore, it is difficult to move the Eclipse workspace between Windows and Linux. It is better to keep the workspace directory for the system you are using but to import new projects into that directory if you want to change the development platform for an application from one OS to the other.
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 anywheresystem mount points that have been proposed and replaced through the years for a second disk.
Fedora maintains the original view that Unix is a multi-user operating system and it regards mountable disks as owned by a user (as USB sticks tend to be). So Fedora prefers a very transient mount point and defaults to /run/media/[userid]/SandboxData.
Ubuntu, however, still uses the old model that no matter how many users share the machine, mountable disks are hardware devices like the CD. So it mounts disks as /media/SandboxData.
Of course there are other options, but the fact that two well known distributions make different choices frees us from expecting that there is one right answer to this question. Therefore, the system will put the disk where it wants to, and any further conventions we create will be symlinks to that system mount point.
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).
...