The current discussion seems to focus on the situation where a singleton process hooks up to OpenOffice. As soon as there are multiple clients for OO the situation is controlled by the operations of the MacroManager. As of my last reports from [EMAIL PROTECTED], the MacroManager in OO is not threadsafe and remotely invoking a macro on document A while another process is running a macro on its document B has indeterminate results.
Our application makes heavy use of both Uno-Xinterfaces and custom OO-Macros to process text into documents. We have both user clients and robotic services that perform these operations and the solutions presented so far won't allow for multiple processes with our behaviors to run concurrently on a box. Given this, it seems to be best for the client processes to be the chickens and to lay instances of OO as eggs. In this model, each workstation has a number of configurations of OO and client processes are assigned to those by some shared client config. Now a client process first tries to connect to a running instance of OO of its specified OO configuration using the bootstrap initialComponentContext to ask for a XBridge or a remoteContext. If not found, the process will start up that instance using (for OO 2.x) the ENV startup parameters. One side effect of this is that disconnect/shutdown issues seem to go away; another is that a 'default user' config can be created to allow casual users to work on OO documents on the desktop without being affected by custom aspects of the service configurations. It's a bit more code work to hook up this way; and it's a lot harder to install properly. - John Sisson -----Original Message----- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Ramon F Herrera Sent: Friday, December 07, 2007 8:23 AM To: dev@api.openoffice.org Subject: [api-dev] Re: Would like to connect to OOo in its own terms Stephan Bergmann wrote: > Ramon F Herrera wrote: >> (1) xContext = Bootstrap.bootstrap(); // starts OO process (plus Windows icon) if not already running > > After step (1), you already have a connection to OOo. That was precisely my discovery. I concluded that Bootstrap.bootstrap() is the only connection method needed to fulfill my requirement ("Would like to connect to 'soffice' in its own terms"). I noticed that the bootstrap() step created the little icon (wonderful visual aid, it helps a lot in development, btw) when soffice was not running, or, if it was running alreay, it just connects to it. But, it turns out that Bootstrap.bootstrap() is less than a perfect solution, as it has a big problem. Read on... My problem of achieving a clean disconnect persisted, so I went through as many tutorials and snippets as I could find. My conclusion was (and still is) this: "it has been determined that Bootstrap.bootstrap() is bad for the termination of your program". In Eclipse, at least I can click on the red square (stop) button, but in NetBeans the process simply keeps on running and the only way to terminate it is from the server side, right clicking the Quickstarter and exiting it. Notice that those are *interactive* ways to terminate the bridge, and what I am really looking for is a *programmatic* way to terminate the bridge. So far, the only programmatic solution involves: (a) Bootstrap.createInitialComponentContext(null); (b) connection = xConnector.connect(con); (c) Keeping the value of 'bridge' around, so I can .dispose() it. I am looking for a clean disconnect, which doesn't use (a) or (b). -Ramon ps: many thanks to everybody, I finally! found a knowledgeable source of OO expertise, I mean *The* source. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
