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]
