Bring it up!

Please make sure you read the Installation section before.

Open a command line window. Go to the core installations "bin" folder:

Subversion users:

Go to workspace_z2_base/z2_base/run/bin (use "\" instead of "/" on Windows).


Git users:

Go to core/run/bin.

Enter ./gui.sh on Linux and Mac OS X or enter gui.bat on Windows. Hit enter.

As a result, a window opens that displays the console output of the runtime and its worker processes. If nothing comes up, please check the console output. Most probably the Java executable was not found or is of an incorrect version. To find out type

java -version

and hit enter. The output should read something like this:

java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Server VM (build 14.0-b16, mixed mode)

The exact details do not have to match. But it should say some version 1.6.x or 1.7.x.

At every start your installation will synchronize with the remote repository. That means, it will download whatever is required and not yet locally available to get the runtime into its target state (and no more!), which in this configuration means that it will start some web applications (as promised) and whatever these need. Also, it will compile - as needed - anything that is not available as binaries in the repository.

Why is this important?

Every local installation, be it for development or production, will always synchronize to the latest content in its central repository - except if there is a very good reason to take isolated content from somewhere else during development (see Development). This feature does not require manual intervention and is the default behavior. That means that you will not experience late integration surprises when it turns out that some system has been running on outdated, locally modified or not reproducable content.

After a short while it should read like this:

 

The buttons on the graphical console are all you normally need to use. Pressing "Sync" will force a new synchronization with the repository and "Exit" will do the obvious: Shut everything down.

The next startup will not require a full sync and as a consequent will be much faster (e.g something in the sub-minute range) - actually most of the startup time will be spent in frameworks like Hibernate.

There are other ways to start the runtime. For server operations and if you do not have a graphical user environemnt, instead of gui.sh (or gui.bat) you can launch the runtime using go.sh (or go.bat) with a number of options that determine the VM settings for the so-called <home> process, whether you will get a GUI or a prompt or neither one.

In the graphical console above note the tab called "Workers". That tab will display an overview of worker processes currently running. The z2-Environment runtime always runs a coordinator VM, the <home> process and a number of worker processes that do the actual work.

The <home> process generally runs very little. It does however take care of basic sanity and house keeping tasks. In particular it will (if so configured) regularly check for the target state of the runtime, including checking on the worker processes, and it will coordinate synchronization with the repository (or repositories). Worker processes are components configured in the repository. Changing their configuration and synchronizing the runtime will restart the modified worker processes.

Why is this important?

Often it makes sense to assign work of significantly different load behavior to different operating system processes. For example: Asynchronous processing of large data sets or of integration tasks with remote legacy systems should preferrably not impact the stability of a front end, customer facing web application. As the z2-Environment is capable of managing worker processes based on a central configuration, we achieve separation of work on the operating system process level without compromising on configuration consistency.

Continue with: Introspection