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? There are a few changes required to the standalone.xml configuration file in JBoss, and you need the database drivers installed. Have all of the servers, drivers, JREs, and versions of Maven been configured to Eclipse?
Its not that you cannot solve each of these problems in a new environment. It just takes days or weeks. The Sandbox makes it all just work.
That's not how WE 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 try to force everyone to use a single solution, but 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. 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 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).
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 execute. 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 Ethernet address).
Although all these applications run https:// in production, 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 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 /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 \var\log\jbossas\standalone on whatever the current disk letter happens to be (R: is the Sandbox convention).
The Sandbox is not, by definition, a production environment. So it generally doesn't require efficient execution. 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 the two would be independent. However, there are a few executables that are different in Windows and Linux, so the Java Runtime, Eclipse, and JBoss are either Linux or Windows and there have to be separate versions of the development disk for the two platforms. 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. In Linux it is mounted in the same way that Linux likes to mount portable disks or thumb drives (as /media/SandboxData).
There is almost no specialized configuration on any operating system. This paper will provide suggestions for configuring the virtual network that are useful guidelines for development, simple debugging, and complex debugging. However, you can use almost any version of any operating system as long as machines that run the IDE (Eclipse) have a GUI and desktop.
This also means that you can customize your OS to be exactly what you want, then use it with different SandboxData disks to do development on different applications (or you can put all the applications on the same SandboxData disk and run them all together).
Sandbox systems tend to be kept more up to date than production systems. If you really want to try something new out while working, it is not unreasonable to work with a stable Beta of the next release of the OS. Having the latest features at hand can be useful.
The SandboxData disks, however, tend to lag behind because they have to match an environment that is already in production. So you will find Java 7 instead of 8, or JBoss EAP 6.2 instead of Wildfly 9.
The Sandbox allows you to edit and debug source. You can change existing files and create new files. You can work with Java source or configuration files. After you are done with basic testing, the changes you make are committed back to the Yale Subversion server. Then they are then used by the Jenkins jobs to build the DEV, TEST, or PROD environment.
So the result of Sandbox development is reflected in changes to SVN. After code goes into production, you can keep your copy of the Sandbox around for further development, or you can discard it and start over again with a fresh new Sandbox in any future project. If you have strong feelings about Linux or Eclipse, you may choose to customize your Sandbox VM to your preferences, and then it makes sense to save it and use it for other development, even for other software projects.
Installation
You need a current version of VirtualBox which you can get from Oracle (virtualbox.org). You can install it on a Windows or Mac desktop or laptop computer which becomes the "host". VirtualBox is an open source project, but Oracle also creates some proprietary extensions that you are prompted to install immediately after you install the base software.
If you launch the VirtualBox application you will see a management console. It displays the Virtual Machines (VMs) that you already have and provides a Wizard for creating new VMs, typically by running the OS installer CD image for Windows or a Linux distribution. If you ask it to start an existing VM, VirtualBox creates a simulation of a full personal computer and even runs a power up BIOS. It then boots from the virtual hard disk image or from the virtual CD image.
The VM displays on the host computer screen as an application window. However, this "application" thinks that it is an OS on a real computer. To make it behave seamlessly on the host monitor, VirtualBox provides some device drivers that you can install on Windows (or build and install on Linux). With the drivers the mouse can move smoothly into and out of the VM window, and cut and paste of text operates between VM applications and host applications.
Once installed, the VM will be a directory of files in the location VirtualBox is configured to store its VMs. This VM is configured by the installation process with specific locations on the host disk and the names of specific configuration features from that specific host. So you to install the VM on another computer, you have to "Export" it to a type of file that is not bound to one specific system.
The Sandbox is distributed as a *.ova file. This is an open standard form of zip file that contains both the machine configuration and the disk image. It can be loaded into VirtualBox (or VMWare for that matter) to create the virtual machine. During installation, or any time before you start the VM, you may need to configure features that are potentially dependent on your local machine configuration. VirtualBox has a feature called "Shared Directory" that allows the host operating system to share one of its directories with the VM (like a network share, but implemented without the network). When the distribution was built, the shared directory was "D:\sandbox", but you may want to turn this off (it is a convenience) or change the host directory path, especially if you do not have a D: drive or are not running Windows on your host computer.
You may be asked to reconfigure things that you forgot to change when you start the VM for the first time. For example, on the computer that created the Sandbox there was a specific physical Ethernet adapter with a specific name assigned by Windows. Your computer will also have an Ethernet adapter, but it will have a different name. VirtualBox will ask you when it goes to replace the old name with the local name on your computer. If you only have one LAN adapter it hardly seems necessary, but in theory you could have two LAN adapters and then it would be important to choose the right one.
It is easy to go back and fix things, but do not rush to install the Sandbox image before you have read the rest of these instructions so you know what the configuration means.
casdev
There is one user named "casdev" with admin (sudo) privileges. You login, run Eclipse, and do all your development as this user. The /home/casdev directory holds the Eclipse workspace and all the casual files. Because JBoss is started from Eclipse, it also runs as casdev. Therefore, the JBoss and Eclipse directories are owned by casdev even though they are installed elsewhere in the file system.
The password for user casdev is not particularly secure, since it can only be used by the developer on the host machine. However, it will not be published here. Ask someone for it.
Where
Oracle Java comes in a standard Red Hat distribution format called an "RPM" that contains both the files and instructions where to put them. Oracle puts a JVM in /usr/local/java. Red Hat official RPMs for JBoss are not available without a subscription, and RPMs for Eclipse are typically several releases behind the current verison. So JBoss comes from http://jbossas.jboss.org/downloads.html and Eclipse comes from http://www.eclipse.org/downloads/ and they are unzipped into subdirectories of /opt.
Then ownership of the directories is assigned to the "casdev" user instead of "root". JBoss contains configuration files and it writes to work directories that are part of the single distribution directory tree, and Eclipse has to change itself whenever you add new software. Eclipse and JBoss could have been put in the casdev HOME directory, but putting them in /opt seems cleaner. They are not, after all, part of your normal development workfiles. The Eclipse workspace that you are using goes in the casdev home.
There are a few things that have to go in the same place in the Sandbox and production. For example, the log files should be written to /var/log/jbossas on the Sandbox because that is where they go in production and that specific path has to go into log4j.xml. The JBoss Server configuration in Eclipse is modified to add -Djboss.server.log.dir=... onto the end of the JBoss start command.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? None 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!
If you take a strong stand that programmers should all do something in one common way, you almost guarantee that your efforts will be subverted by people who believe that your choice is wrong. The Sandbox is not a single choice but rather a family of almost identically configured mix and match components that almost anyone can live with.
Hypervisor
Oracle Virtualbox is free, powerful, easy to use, and can be installed on all Windows, Mac, and Linux computers. Other options (Hyper-V, Xen, VMWare Player) run on single operating systems so you have to convert VMs from one to the other (and it turns out that Virtualbox is the recommended utility for a lot of the conversions). It is a desktop tool friendly to developers rather than a production server deployment tool like Hyper-V. VMWare has been around longer and goes through more extensive testing before much more infrequent releases, but if a feature breaks when there is a new release of Windows or Ubuntu, then you have to wait a long time for the next release to fix it. Virtualbox has frequent releases as an open source project and adapts more quickly.
Although Virtualbox aspires to be something you could use for production servers in a machine room, it is not yet something one would recommend over an alternative like Hyper-V. However, for simple desktop edit, compile, and debug it is simple, reliable, and convenient. It may be that the drivers for the emulated video card don't support modern features, and that the passthrough of USB 3 hardware devices to the VM has problems. You don't need that stuff to run Eclipse.
Desktop
Originally the Production Services group at Yale tried to convince use to use the same VM in development that they use in production. However, that VM only has the character terminal user interface, and most people these days do not want to write code using only the vi editor. So to use that machine you would have to use Eclipse on another computer, then install onto the VM and remotely debug. It is a possible model, but it turns out that Production Service never provided the tools needed to actually create and maintain accurate versions of their VMs.
It is much simpler to upgrade the VM to include a real desktop and run Eclipse on the VM itself instead of on a separate machine. Given that any user interface is an addition, there was no particular reason to prefer Gnome to KDE to Unity or any of the other choices you make from one Linux distribution to another. Eclipse will work under any Linux "desktop" system. If you feel strongly about it, switch to whichever one you want.
Cutting and pasting text with the "clipboard" function and dragging and dropping files are functions actually performed with the user interface and not the Linux OS. Virtualbox has had a lot of trouble getting drag and drop of files to work across systems, in part because it is different for KDE and Gnome and so on. If you get it working, there is no guarantee that the next release of Linux won't break it again. Even if you accept the default Gnome desktop that comes default with your preferred distribution, if the Gnome drag and drop is broken and the KDE drag and drop works, then you may want to install just the KDE File Management utility (Dolphin). It will drag along 100 megabytes of KDE lib files, but then you have two file managers and can drag and drop files to whichever one works.
Virtual USB Stick
Even if Eclipse is not automatically installed in your distribution, you can find it in the Software tool. It is almost always one or two releases (years) out of date and generally you don't want to run something that old. However, if you do choose to install it, there is some directory where the package manager tool (yum or apt-get) wants to install that particular program. Feel free to use the standard tools to install Eclipse or Java or JBoss where the distribution wants to put them.
The Sandbox comes with its own copy of everything, and it puts that stuff somewhere that no distribution would normally install Java or Eclipse. It puts them where a Linux system mounts CDs and USB Sticks (the /media directory). In that sense, the Sandbox puts all its files on a "virtual USB stick" although actually it looks to the VM like a small additional hard disk. This has two advantages. First, the Sandbox cannot conflict with any OS convention for where stuff is supposed to go. Second, this is a more natural way to arrange things if you want to work with the Sandbox files for Shibboleth, then "eject" the disk with those files and mount the disk with Sandbox files for IIQ.
You may want to move the Eclipse workspace to your real Home directory (or the /home/casdev directory since you login as user "casdev") if you are doing something experimental and don't want to mess up the original workspace in the Sandbox.
This way we avoid the eternal argument between /opt and /usr/local and other places where different people believe stuff should go.
One from Column A
Generally speaking the Sandbox VM environment involves choosing two separate components.
- You need an OS VM. Typically it will run CentOS, Fedora, or Unbuntu. You can just pick up the OS configuration last used for the software you are planning to develop, or you can choose one specific OS VM to use for all your development and customize it to your preferences.
- You need the SandboxData disk/directory-tree for the particular software package you are planning to work on . By separating out the CAS project files on one virtual disk, and the Netid project files on another virtual disk, you can keep the same OS VM with your customizations and switch from one software development project to another by switching mounted disks.
Eclipse, not /etc
In the operating system servers are configured in /etc or the registry, but in the Sandbox you configure every Java Runtime, every JBoss or Tomcat server, and every Maven instance in Eclipse. In the system Java and JBoss are started at as background processes at boot time, but in the Sandbox your run Maven or start JBoss in debugging mode by clicking the task bar in Eclipse.If you have installed a J2EE server in the OS, then you have to stop it before starting JBoss under Eclipse or else you have to configure the Sandbox JBoss to use a different port that the 8080 default.
Of course, if you have a version of the Sandbox configured to work on both CAS and Netid (because they interact) and CAS runs on JBoss and Netid runs on Tomcat then you may have to configure two port numbers anyway. You just don't want the OS servers adding to the complexity.
1001
There is a generic developer userid named "casdev" (because the Sandbox was first created for CAS, but it can be used for any application). This user must be configured to the OS as Linux user 1001 because it is the userid number that is stored in the SandboxData disk directory as the owner of all the directoriesand files. The Sandbox OS is typically configured to log this userid in when you boot the VM. Typically "casdev" starts Eclipse and then everything is managed and started from Eclipse as part of this interactive login. So everything runs under the "casdev" user, and that user must have read and write access to the small number of OS directories that may be used during execution (specific subdirectories of /var/log and /media for example). Any directory permission problems will not show up until you run the code in DEV, but that is typically soon enough to deal with them.
Because it is 1001 and not "casdev" that is used in all Linux rules, it would be fairly simple to rename "casdev" to a different name if you object to it. Just keep the 1001 number.
R:\
The Sandbox OS can be Fedora or Ubuntu, but it can also be Windows. Java is system independent and all the tools (Eclipse, JBoss, Maven) are written in Java. You can develop CAS in Windows and then deploy it to production Linux servers and everything works.
Unfortunately, the SandboxData disk cannot be moved between Linux and Windows. While Java can be stored in the same directory on the disk for both systems, the Java executable is either a Linux program or a java.exe Windows program. Eclipse also inserts the disk letter when it configures an external file in Windows, while disk letters do not exist in Linux. So there have to be separate SandboxData images for Linux and Windows even though the component (Java, Eclipse, JBoss, or Maven) is in the same relative directory on each image.
Misc
CAS, Shibboleth, and Netid are examples of programs that run under SSL in production but run normal HTTP on port 8080 during development in the Sandbox.
Some files have to have explict fully qualified path names to a log, cache, or configuration directory. The Shibboleth WAR needs to know where /usr/local/shibboleth-idp is, and the log4j.xml file has to point to the /var/log/jbossas/standalone directory. You have two choices. You can use the standard OS file (strongly recommended for /var/log/jbossas/standalone) and on Windows you can create the C:\var\log\jbossas\standaone directory. Alternately you can create symlinks in the system that redirect the path to somewhere in the SandboxData disk. Remember, the the casdev user has to have write access to such directories.
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 accumulate in applications that run for weeks without being restarted, but that is not a problem for code you debug and restart every few minutes. 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" that 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:
- You have to configure the VM (the *.vbox XML file) using the Virtualbox Manager to have two SATA disks, one for the OS and one for the SandboxData.
- You then have to boot the OS and configure it to mount the SandboxData disk and its file system as a directory in a well known path. Search for the "Disks" GNOME utility which is an easy to use way of changing the /etc/fstab file. The smaller "VBOX HARDDISK" that is device /dev/sdb1 should be configured to mount at boot time. Edit Mount Options and curiously turn "Automatic Mount Options" OFF and then type in a mount point. This will create a line in fstab of the form "/dev/disk/by-uuid/6a61a74b-df34-4038-bc70-ee6cf02d5cf0 /media/SandboxData auto ..."
- It is probably not a best practice to choose the system mount point as the explicit path used to configure something in Eclipse. So a simpler directory should be symlinked to the mount point and that should be used in application configuration.
There are several ways to mount disks in Windows and Linux. The choices all derive from two ambiguities:
- Linux and Windows both support multiple users, but in practice only one person typically logs on. Still the system has provision for there to be another user and that has an effect on disk mounts.
- Some disks are transient (USB flash drives) and some are permanent (a SATA hard disk installed inside the computer).
Since Linux cannot automatically decide if a disk belongs to one user or is supposed to be shared, and whether it can be dismounted and replaced or is mounted permanently, it is up to the users and administrators to configure things appropriately. Generally Linux will default in favor of the single user transient model (the USB flash drive) unless it is told otherwise.
While it is possible to switch from one software project to another by keeping the same OS disk and changing SandboxData disks, it is unreasonable to expect to do this without rebooting. That is, we do not intend to configure the Sandbox VMs to believe that SandboxData is a USB disk that you can eject and replace with another disk on a running system.
In Fedora, if user "casdev" mounts a disk then the mount point defaults to being something in the transient "/run" directory that is tied to the userid that mounted it. Specifically, the default location is /run/media/casdev/SandboxData. Ubuntu, however, uses a somewhat older standard where mounted CD drives were associated with /media/cdrom and so it wants to mount the same disk as /media/SandboxData. It is difficult to change the defaults of the system, and for this purpose it is unnecessary. So we adopt the Ubuntu default as the configured behavior on all Linux systems.
However, having decided that the mount point of the disk will be /media/SandboxData, that does not mean that we should use that path in Eclipse configuration windows. The option is then to symlink something simple like "/SandboxData" or "/home/casdev/SandboxData" (a.k.a. ~/SandboxData) to the mount point.
In Windows, mounting a disk typically generates a disk letter. The convention for the Sandbox is to use letter R: simply because it is unlikely to be used by anyone for something else. However, there are several ways to create a disk letter in Windows. In some cases the mapping is visible only to the user who does it, while in other cases the disk letter is global and is seen by all users on the machine. So Windows has some of the same problems as Linux, but the system details are different.
There is one more problem to mention. When a disk is initialized, it is given a unique identifier (a UUID) written in the disk label. This allows external disks to be uniquely identified no matter which USB port you plug them into. It also helps identify internal hard disks when the SATA cables become disconnected and are then reconnected to different ports. The Linux /etc/fstab file and the Windows Registry identify disks by the UUID and not by their label. So if you reconfigure a VM replacing one SandboxData disk with another, then when you boot it up again the system will know it is a different disk and will not automatically mount it. You have to use the Disks tool to add an additional line in fstab to mount the new UUID.
Obviously, although this discussion has assumed that the SandboxData files are all collected on a mountable hard disk image (a best practice), nothing prevents you from creating a Sandbox configuration where the files that would be on the second hard disk are instead copied or unzipped into a directory tree on disk. This is particularly attractive if you have decided to promote your sandbox development to the native operating system on your laptop, and now that you are not using a VM it is harder to mount a virtual disk file.
Installation
The Sandbox conventions do not depend on the software that creates and manages the virtual machines. Since this is not a production environment, the best choice is the one that is easiest to use. VirtualBox is free, can be installed on Windows, Linux, or Mac, and has convenience features for the developer. If you were creating virtual machines that you would immediately deploy into a IaaS cloud environment, then VMWare Workstation might be the best choice when developing for a VMWare fabric, and Hyper-V might be the best choice for a Microsoft fabric. The Sandbox, however, isn't going anywhere. The end result of all your work is source checked into Subversion that will get built and installed with Jenkins.
However, it is not a good idea to mix hypervisors on the same machine. They get into conflicts over the CPU VM support (VT-x, Nested Paging, etc.). So while you would never install VMWare or Hyper-V just in order to run the Sandbox, if you already have them installed for other projects then it is not necessary to rip them out and replace them with VirtualBox. Running a Sandbox OS disk on VMWare or Microsoft requires changing the hard disk format, creating a VM configuration (number of processors, size of memory, etc.), and then after the OS boots up you have to install the vendor specific Guest Support services and drivers. If you do not know how to do this, ask someone for help.
It turns out that VirtualBox is generally regarded as the best tool to convert one virtual hard disk format to another (VDI, VMDK, VHD). So even if you are not going to use it to run virtual machines, you may need to install it somewhere to do the conversion.
Download and install the current version of Virtualbox from virtualbox.org (at least 5.0.0). Run the installer. Launch the VirtualBox Manager.
A Virtualbox VM is a directory on disk. There is a xxx.vbox file that configures the memory, processors, network, and options of the VM, and a large xxx.vdi file that is the virtual disk.
A VM can become slightly attached to the environment in which it last ran. For example, by default a VM remembers the fully qualified path to any *.iso DVD image files that were previously mounted in its virtual DVD reader. It also may be connected to a virtual network that was configured with a name ("natnet1") on the previous system. If you copy a Virtualbox directory from another computer, you may have to flush the history of previously mounted DVD images and reconnect it to the name of a network that exists on your host computer before it will start up properly.
Sometimes the virtual machine has to be associated with a particular device on the real machine. Your computer may have more than one Audio adapter, and the virtual audio of the VM has to be associated with one of the real audio drivers on your computer. Similarly, you computer may have multiple LAN adapters (wired, wireless, etc.) and in certain network configurations (like "Bridged") the VM has to be associated with one of these adapters. However, if the VM is moved from one computer to another, then the new computer may not have the same type of audio or LAN adapter and the device name of the association has to be changed.
A VM can be archived in OVA format. This is a semi-standard zip file that contains a special version of the configuration data and a compressed version of the disks. Virtualbox will read an OVA and explode it into a real VM directory. You still may have to go back and change the network names.
There is also a very convenient feature called a "Shared Directory". This allows the host computer to share a directory or an entire disk with the Sandbox VM. It is very much like a disk shared over the network, except that the connection is directly between the host computer and the one VM so there is no extra security environment. Windows users may recognize this arrangement because it is exactly the same as a Remote Desktop Client sharing a disk with your own terminal session on another computer. Because you are the real user on both ends, there is no need for additional authentication and security. However, the directory to be shared is part of the VM configuration and it will break if you shared the D:\ drive on one computer and then move the VM to another computer that doesn't have a D:\ drive. You may have to redefine or delete the Shared Directory before you can start the VM.
casdev
There is one user named "casdev" with admin (sudo) privileges. You login, run Eclipse, and do all your development as this user. The /home/casdev directory holds the Eclipse workspace and all the casual files. Because JBoss is started from Eclipse, it also runs as casdev. Therefore, the JBoss and Eclipse directories are owned by casdev even though they are installed elsewhere in the file system.
The password for user casdev is not particularly secure, since it can only be used by the developer on the host machine. However, it will not be published here. Ask someone for it.
The VM
The VM is a standard Virtualbox 64 bit Linux configuration. With JBoss running the used memory only gos up to does not exceed 1.3 GB, so the amount of virtual RAM for the VM could be reduced to 1.5 or 2 GB if you need to run two VMs on an 8G laptop.
...