...
Different Linux distributions put the same component in different directory locations. There is no single correct place to install a program, and if you decide to use your own customized environment to perform the Sandbox development function you may have already installed some of the same programs in the location you prefer. The only safe thing is for the Sandbox to provide all its own copies of every program on which it depends and to put all this stuff in a separate location that cannot possibly conflict with any default "system" version of the same code. So the Sandbox is packaged as a separate small self contained virtual disk drive that you mount as an additional disk on a base operating system. The Sandbox disk image contains one or more Java Runtimes, JBoss servers, Eclipse IDEs, but they are always in the same relative location. Typically you only need one release of Java for one application, but when you are developing a version upgrade that will also be accompanied by an upgrade of Java on the production systems, then the Sandbox may have both the new and the old Java installed.
In the operating system, the default version of Java is controlled by system commands. In the Sandbox, it is controlled by the configuration of Java versions in Eclipse.
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). 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 verify that things work with normal directory ownership rules, wait until you get to DEV.
In the operating system servers are configured in /etc or the registry, but in the Sandbox they are configured in Eclipse. In the system they are started at boot as services, but in the Sandbox they are started and debugged by Eclipse. There would be a conflict if the real operating system starts the standard version of a server up on a standard port and the Sandbox disk is configured to use the same port. Then you have to change either the system or the sandbox to address the conflict. Otherwise the Sandbox does not know or care what version of Java or Eclipse or JBoss you have configured in the system because the Sandbox starts its own copy with the right version from its own directories.
If you need to develop two different Yale applications at the same time (CAS and Netid depend on each other for password change functions) then each may use a different version of Java and different Application Servers (CAS uses JBoss and Netid uses Tomcat) A Sandbox configured for this development may have two Java Runtimes and both JBoss and Tomcat in side by side subdirectories of the same parent directory. However, the basic directory structure of all Sandbox disks is the same and once you learn it you know where JBoss is going to be stored even if, from one application to another, it may be a different version number of JBoss in each Sandbox.
No application ever depends on the Eclipse that built it, so if the Sandbox contains Eclipse Luna (4.4) and you want to upgrade it to Mars (4.5), then that should always work.
In production JBoss runs under its own userid (typically "jboss" or "jbossa") that owns its own directories. In the Sandbox all the files used by Eclipse, the applications, the application servers, or anything else unrelated to the system are owned by the user "casdev" who is Linux user number 1001. This means the Sandbox cannot debug disk permission problems that will show up only in DEV. You can wait until you get to DEV to find and fix them. Since the application runs under JBoss that runs under Eclipse that is running as an interactive application, that whole process tree has to run as the logged in user.
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 when it 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.
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 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 typically owned , by the casdev userid.
Sandbox is not Production
...
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 for accumulate in applications that run for weeks without being restarted in production. OpenJDK is fine for debugging a program that you , but that is not a problem for code you debug and 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 Developers frequently prefer being on the latest and greatest version of Fedora rather than running an older Linux Kernel in Centos just because that is what Red Hat supports for production.
To fully exercise every part of an application you may have to install optional libraries in the system. For example, the Netid application uses the Kerberos 5 administration libraries that would have to be installed with yum or apt-get. However, unless this additional function is an essential part of your debugging, then you open a big can of worms trying to get the Sandbox to support this sort of function. You will never get the Netid application to actually do Kerberos 5 administration in the Sandbox because it turns out that the Java native code that provides that interface only works in 32 bit mode and only on an older version of the library. It is much better to do what Netid does and have a install parameter "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 practicethat turns all Kerberos administration calls into noops since you are almost never actually testing that particular function of the application.
Two "Disks"
The core of the Sandbox is a separate disk image (named "SandboxData") that contains the Java, Eclipse, JBoss, Maven, database drivers, and so on. This disk can be cloned or the VM manager (VirtualBox) can create a fixed base disk shared by multiple machines with separate difference files that hold the changes each VM makes.
The last programmer to work on an application will leave a VM with a particular version of a particular OS that was last used in development. Try to live with it. If you can't, then you can switch to another OS Sandbox disk, but then you will have to connect it back to the SandboxData disk that contains the development files.
The SandboxData disk files are owned by user 1001 group 1001. The operating system you boot should have configured this user number to be "casdev" for sanity sake.
This is a three step process in Linux:
...