Xebra Server Administration
Run Xebra Server
This section describes how to run the server if xebra was installed manually.
- Make sure the server config file is correctly set up. I.e. don't forget to remove '.exe' for linux, make sure to select the 'F_code' directory if you compiled with finalization.
cd $XEBRA_DEV/eiffel_projects/xebra_server EIFGENs/xebra_server/F_code/xebra_server config.srv
cd %XEBRA_DEV%\eiffel_projects\xebra_server EIFGENs\xebra_server\F_code\xebra_server.exe config.srv
- Or to see a list of run arguments type instead
- Stop the server by typing
- For a list of server commands type
Run Xebra Server in EiffelStudio
This section describes how to run the server withing EiffelStudio if xebra was installed manually.
- Launch estudio and compile the project $XEBRA_DEV/eiffel_projects/xebra_server/xebra_server.ecf
- Go to the Execution -> Exceptions Handling dialog. Check "Filter Exceptions?" and change DEVELOPER_EXCEPTION to "Ignore".
- Open the Execution -> Execution Parameters dialog and set "config.srv" as argument (see below for more info about run arguments).
- Fill in the Xebra Server Config File
- Browse to http://localhost/helloworld/. The server now translates, generates, compiles and finally runs the helloworld application.
Run in Create Webapp Mode
You can use the server as a tool to only translate, generate and compile a webapp. The application will then not act as a 'server'. Use the '-c' option for that matter.
$XEBRA_DEV/bin/xebra_server $XEBRA_DEV/conf/config.srv -d 6 -c $XEBRA_DEV/www/demoapplication/config.wapp
You can interrupt and terminate anytime by hitting any key.
The server automatically launches the following modules:
- mod_http: Listens to requests from the http plugin (Apache Module or IIS7 Handler) on port 55001. These request are forwarded to the appropriate webapp.
- mod_console: Reads input from the console. The commands described below can be invoked.
- mod_cmd: Listens to command request from the webapps on port 55002.
Managed and Unmanaged Webapps
The server can handle two different types of webapps: managed and unmanaged. The attribute "managed_webapps" in the server config file specifies the path to the root of the managed webapps. On startup the server scans this path for webapp config files and loads them. Managed webapps are translated, generated, compiled and run automatically by the server. All managed webapps are run locally. Unmanaged webapps are specified under "unmanaged_webapps" in the server config file. These have to be managed manually by the user but can be run on any other machine. The xebra server application can be used as a tool to only translate, generate and compile a webapp by using the -c option.
If the option -u was set, the server treats all managed webapps as unmanaged ones, i.e. it does not translate, compile and run the webapps but just tries to connect immediately. This should be used when a webapp is launched in estudio for debugging and the server does not need to run and shutdown the webapp.
By default, a managed webapp is set to Development Mode which means that the server checks everytime a request was made if the webapp needs to be retranslated and compiled. This makes access to the webapp very slow. As soon as development of the webapp stopps, dev_mod should be set to off.
Fire off a webapp
If the server crashed and therefore could not properly shut down all managed webapps, they will still be running when the server is relaunched. Hence, the socket will be occupied when the server tries to launch a webapp. Use the fire command to fire off a possibly running webapp. The fire command tries to directly connect to the webapp and send a shutdown signal regardless if the webapp process is owned by the server or not. This command is also available for unmanaged webapps.
USAGE: xebra_server.exe <config_filename> [-d <debug_level>] [-u] [-c <Webapp config file>] [-v] [-nologo] OPTIONS: Options should be prefixed with: '-' or '/' -d --debug_level : Specifies a debug level. 1: Start and stop of overall application 2: Application configuration 3: Start and stop of main components 4: Information about tasks that are performed 5: Information about subtasks that are performed 6: Very verbose information about subtasks that are performed (Optional) -u --unmanaged : If set, the server treats all managed webapps as unmanged webapps. (Optional) -c --create_webapp: With this switch the server can be used as a tool to translate, generate and compile the specified webapp (Optional) -? --help : Display usage information. (Optional) -v --version : Displays version information. (Optional) --nologo : Supresses copyright information. (Optional) ARGUMENTS: <debug_level> : The debug level (1-6) <Webapp config file>: The webapp config file NON-SWITCHED ARGUMENTS: <config_filename>: The path of the config file to use.
- 'help': Displays a list of commands
- 'exit': Shuts down the server. - 'reload': Reloads the server configuration file. - 'shutdown_webapps': Shuts down all webapps.
- 'mlaunch <name>': Re-launches a server module. - 'modules': Displays the available modules. - 'mshutdown <name>': Shuts down a server module.
- 'clean <name>': Cleans, re-translates, compiles and launches a webapp. (Managed webapp only) - 'dev <name>': Sets developing mode of a webapp to on. (Managed webapp only) - 'dev_all': Sets dev_mod to on on all webapps. - 'dev_off <name>': Sets developing mode of a webapp to off. (Managed webapp only) - 'dev_off_all': Sets dev_mod to off on all webapps. - 'dev_on <name>': Sets developing mode of a webapp to on. (Managed webapp only) - 'disable <name>': Disables a webapp. - 'enable <name>': Enables a webapp. - 'fire <name>': Sends shutdown signal directly to webapp. - 'shutdown <name>': Shuts down a webapp. (Managed webapp only) - 'translate <name>': Forces re-translation of webapp (without cleaning). (Managed webapp only) - 'webapps': Displays the available webapps.