The Open Office Server Daemon

The daemon

The daemon is based on the oood daemon written in python by Joerg Budischewski that you can find at The current daemon is written in Java. A big part of this documentation is also taken from oood.

This daemon controls a pool of 'anonymous' office instances (workers). The workers can be used as backend for java/python/C++ batch processes for document conversion, mail merges, etc. . You don't need to rewrite your current scripts, a client connects to a daemon-controlled office just as if would connect to a normal office. The daemon ensures, that only one client at a time is connected to one openoffice instance. Workers get restarted after a certain amount of uses or after office crashes. A client can connect to a daemon as if it would connect to a normal 'non-daemoned' Open office server, so you don't need to adapt your code/scripts.

'How it works' diagram

Why a daemon ?

For various reasons :


Currently, the daemon is in beta testing, meaning that features are working, but heavy testing must be done.


The daemon and its usage is in general INSECURE. Everyone, who can connect to the daemon can use the underlying office instances and thus has full access to the machine (with the daemon's user rights) and via socket communication to other machines accessible via sockets from the worker machine.

All worker instances run under the same (= the daemon's userid) meaning that a menace user may spy other worker office instances.

However, some simple limitations can be done.

You should use this solution only in a trustworthy environments.


Open Office Server installation

The following informations are only needed if you want many users in parallel.
For one user at a time using a simple queue, a simple Open Office installation suffice for the daemon.

The office daemon works on an arbitrary number of office user installations, which must have been created from the same network installation with a single system user.
Ideally you create a new system user (e.g. oodaemon) therefor, but if you just want to try it out, you can use your normal system user.

( The following description is more or less copied from a mail by J. Barfurth in ).

First do a new multi-user installation ( start $ setup -net on linux/unix ) from the downloaded installation set. Afterwards, create multiple single user installations by starting (use 01 instead of XX)

     $ setup -d /home/ooodaemon/ooServerInstance_XX ( on windows : setup.exe -d C:/oodaemon/ooServerInstance_XX )

from within the office/program directory. After the setup run, edit ~/.sversionrc file and replace x.x.x with x.x.x_srvXX.
Repeat these steps with XX = 02, 03, ... . You need as many installations as you expect concurrent users. You may also start with a low number and add instances later on.

Afterwards, your .sversionrc file should look like :
[Versions] x.x srv01=file:///home/oood/ooServerInstance_01 x.x srv02=file:///home/oood/ooServerInstance_02 x.x srv03=file:///home/oood/ooServerInstance_03

( on windows : adjust the path to the correct form )

Daemon installation

  1. open config/oodaemon-config.xml and change :
  2. ANT : configure config/
  3. shell scripts : configure scripts/env.* (.sh for linux and .bat for windows) .


Usage patterns

You can now connect to the daemon with an arbitrary (Java, C++, python) client program in exactly the same way as you connect to a normal OpenOffice.
The daemon delegates your request to one of its worker offices. For the time of usage, this worker office is exclusivly used by your client program. The end of usage is detected by the daemon through a breakdown of the interprocess bridge (which occurs, when the last reference is gone, the client explicitly disposes the remote bridge or the client process terminates).

How to use it

The basic usage of the daemon is to run it in background, then ask for information or stop it using another process called "admin".
WARNING : The daemon is designed to be stopped using ant stop, killing it other ways may lead to uncontrolled server instances still running in background that would need to be killed manually.

You have several ways to launch it :


Log levels (increasing order) :
You can write your own logger, if needed, by implementing Logger abstract class (see for an example).
NONEno output, nothing, nada
ERRORonly errors and fatal errors will be displayed (stack traces not available)
INFOinformations about the execution process will be displayed
WARNINGwarnings displayed added to previous level informations
DEBUGdebug information ( + exceptions stack traces )
DETAILED_DEBUGdebug + minor informations (exceptions during tries, sleep, etc...)



All requests to the office are tunneled through the daemon process. This means an additional load on the server machine and a performance overhead for every request. This is typically neglectable when your call frequency is low (say less than 10 Calls/s), but becomes a significant overhead for higher call frequencies.


Robustness and stability is certainly a keyfeature of a daemon. The following situations are currently handled:


As you are used to when using OOo, this thing is LGPL.


Please give feedback to the OpenOffice community through mailing list.
If you have questions or feedback for the first python version (oood) : Joerg Budischewski
If you have questions or feedback about this java port : Jounayd Id Salah (aka jis)