...
You need an operating system. The 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. 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 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 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)"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 things.
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 . 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 executeand 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 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.
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 virtual Ethernet addressadapter).
Although all these applications run https:// in productionFor development and debugging, 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 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 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 If a directory has to be configured in some property file, then it is probably 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 /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 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 on whatever the current disk letter happens to be (R: is the Sandbox convention").
The Because the Sandbox is not , by definition, a production environment. So , it generally doesn't require efficient executionmatter if it runs a bit slower. 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 there second disk could be shared by everyone, but the java, javac, eclipse, and other executable programs are system dependent and even the Eclipse workspace ends up remembering system dependent path information. So there are two versions of the second disk, one for Linux and one for Windows. 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.If you are already using the R: disk letter for something else, it will be vastly easier to move the old data and free up the letter than to try and find and reconfigure all references to R: that Eclipse has stored away.
In Linux there were many possible places to mount the second disk. Most Linux directories are for permanent files. There can be more that one Sandbox, and you may switch from one to the other when you change the project on which you are working. On the other hand, the Sandbox probably should not look as transient as a thumb drive you plug in temporarily, which in Red Hat systems is in "/run/media/[userid]". The generally accepted place for files of medium persistence seems to be in /media, specifically /media/SandboxDatamemory 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-V.
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.
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 references.
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 anywhere.
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).
The Sandbox OS may be more current than the production system. Java applications don't care if they run on Windows or Linux, so they clearly don't care about the difference between Centos 7 and Fedora 22. You may find the lastest system features more convenient, or you may prefer the old version of the desktop and hate the changes in the latest version of Gnome.
...