Issue 70428 - Add new java methods to start OpenOffice.org even if the jar files are not in the installation directory.
Summary: Add new java methods to start OpenOffice.org even if the jar files are not in...
Status: ACCEPTED
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: OOo 2.0.4
Hardware: All All
: P3 Trivial with 2 votes (vote)
Target Milestone: 4.x
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-14 17:10 UTC by helloworld82
Modified: 2017-05-20 11:31 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Path for the bootstrap method (4.43 KB, text/plain)
2007-01-17 17:13 UTC, helloworld82
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description helloworld82 2006-10-14 17:10:42 UTC
Currently, it is difficult to use the OpenOffice.org UNO bindings for Java
within a framework. Frameworks often use a custom class loader and need the jar
libraries in a local folder. Thus, they cannot load classes from an external
directory. Thus, most java programmers use a custom class loader to load the
OpenOffice.org libraries, like described in 
http://technology.amis.nl/blog/?p=1284. 

The Eclipse Rich Client framework for example can not be used without modified
UNO bindings for Java. 

That problem can be solved by adding a new "Bootsraps.bootsraps()" method and a
new "OOBean()" constructor taking as parameter the path to the OpenOffice.org
installation. These methods would not require that the jar files are located at
the OpenOffice.org installation directory.

I.e.:

/**Bootstraps OpenOffice.
  * @param ooHome installation directory of OpenOffice.org
  */
public void com.sun.star.comp.helper.Bootstrap.bootstrap(String ooHome) 

/**Class constructor taking the installation directory of OpenOffice.org as
argument 
 * @param ooHome installation directory of OpenOffice.org
 */
public com.sun.star.beans.OOoBean(String ooHome)

To overcome the problem of incompatibilities between OpenOffice.org versions,
these methods could check if the OpenOffice.org binary has the same version as
the jar files.
Comment 1 Stephan Bergmann 2006-10-18 09:38:31 UTC
I am not sure whether it is a good idea to have copies of OOo jars outside the
OOo installation (the two-stage approach of OOo's "simple bootstrap" facility is
an alternative), but I also think we need thinks like Bootstrap.bootstrap with
an explicit OOo-home argument, and consolidation of the ways how the first stage
of simple bootstrap, Bootstrap.bootstrap and the OOoBean (-> jl) find an OOo
installation.  So I am taking ownership of this issue...
Comment 2 Stephan Bergmann 2006-10-18 09:39:06 UTC
.
Comment 3 tobiaskrais 2006-11-14 09:01:46 UTC
I have an additional wish for this feature: it should be possible to add certain
PropertyValues to the bootstrap process. These properties should have the same
features as the commandline OOo start options have, e.g.:
-nofirststartwizard
-headless
-invisible
-norecovery
-...

For background discussion see
http://www.nabble.com/-api-dev--Multiple-instances---creating-user-installations-tf2607718.html

Greetings, Tobias
Comment 4 helloworld82 2007-01-12 13:46:59 UTC
What it the state of this bug? (Is the work in progress?)

Do you need some help?
Comment 5 Stephan Bergmann 2007-01-12 14:11:33 UTC
@helloworld82:  No, not yet started.  (Of course, you are welcome to send in
patches.)
Comment 6 helloworld82 2007-01-17 17:13:28 UTC
Created attachment 42245 [details]
Path for the bootstrap method
Comment 7 helloworld82 2007-01-17 17:16:48 UTC
I added a bootstrap method to accept a string leading to the OpenOffice.org
installation directory. Thanks to that, the OpenOffice jar-files do not need to
be in the OOo installation directory. This makes it easier to deliver Java Web
Start application, servlets or eclipse RCP application which uses OOo.

Programs that make use of bootstrap(String ooBaseDir) method can only start if
the $LD_LIBRARY_PATH was  set correctly.  In my case, I had to set it to
following values: export LD_LIBRARY_PATH=/opt/openoffice.org2.0.3/program

I plan to also change OOoBean in such a way that it also accepts a string
leading to the OpenOffice.org installation. 

I did not include the possibilities to add property values as tobiaskrais
suggested it, because I am not sure how he wanted that feature to be implemented
(Can you give me an example – how calling the bootstrap method should look like?).

@sb: can you please look at the patch and say me what I should change? Is that
enough ? I never contributed something to OpenOffice.org.

Regards,
Daniel
Comment 8 Stephan Bergmann 2007-01-18 08:43:16 UTC
Daniel, thank you for the patch.  I will look at it, hopefully sometime next
week.  Anyway, in case any code contributed by you should be included, you need
to sign the JCA first, see "How to submit code to OpenOffice.org" at
<http://contributing.openoffice.org/programming.html>.
Comment 9 Stephan Bergmann 2007-01-19 15:53:13 UTC
Daniel:

- I still do not think that moving the OOo UNO jars outside the OOo installation
is a scenario we would want to support.  (As one of the main maintainers of this
code, I at least am not interested in this additional burden.)  My motivation to
have a bootstrap method with explicit OOo path is rather to make bootstrap more
reliable (see below).  If this change happens to make the unsupported "jars
outside" scenario work for you, then fine for you.

- The unreliable part of the existing bootstrap() is that
NativeLibraryLoader.getResource can find any soffice executable, not necessarily
the one from the same OOo installation as the calling juh.jar.  The irony is
that at least in the "simple bootstrap" (com.sun.star.lib.loader.Loader)
scenario, the path to soffice is already determined when bootstrap() is called,
so could be used instead of NativeLibraryLoader.getResource to increase
robustness.  (Thinking about it, another---better---approach would be to change
bootstrap() so that it reliably finds the soffice executable belonging to the
same OOo installation as the juh.jar.)  Therefore, I do not think it is a good
idea to also build a new bootstrap(String) on the unreliable
NativeLibraryLoader.getResource indirection.

- juh.jar is part of URE, independent of OOo.  Functionality to start an soffice
with an explicit path to that soffice is thus probably not acceptable in
juh.jar.  (One could argue that the existing bootstrap() has the same problem,
but could also counter that bootstrap() only guarantees to bootstrap "the
component context from a UNO installation," not necessarily a full OOo
installation.)  This is a point that makes the whole issue rather delicate IMO
(and one reason I myself have not yet done anything).  :)

- Why bootstrap(URLClassLoader) instead of bootstrap(ClassLoader) and removing
the bad cast from Bootstrap.class.getClassLoader()?

- Polluting the global stdout/stderr is not acceptable (System.out.println,
printStackTrace).

- Why unnecessary premature File.exits check?  (Situation can change until
directory is actually used, in which case an exception would be thrown, anyway.)

- Catching and ignoring MalformedURLException is not acceptable.  (If it "cannot
happen," transform it into some RuntimeException.)

- File.toURI is not available in Java 1.3.1, which is still the lowest common
denominator for OOo.

- In a single patch please concentrate on fixing a single issue, restrain from
doing unrelated cleanup (Thread.currentThread().sleep, ...), and please do not
introduce new, unrelated whitespace.
Comment 10 Stephan Bergmann 2007-01-25 13:31:36 UTC
See related issue 66050.
Comment 11 mvincent 2007-04-11 09:42:30 UTC
Hi,

I have developped a SWT/JFace (even RCP) application embedding Open Office. This
application is launched via JNLP. I resolved a similar issue by rewriting the
method LocalOfficeConnection.getProgramPath() (package officebean.jar) in order
to give the possibility to provide a system property to locate the Open Office
program path

=== The key snippet in the method is just as follow
mProgramPath = System.getProperty("office.home");
if ( mProgramPath == null ) {
   File path = NativeLibraryLoader.getResource(this.getClass().getClassLoader(),
aExec);
   if (path != null) 
	mProgramPath = path.getParent();
}
===

This code has the advantage to resolve the issue without changing officebean
API. For the moment I must release my own officebean.jar via JNLP, however, I do
not need to override the officebean.jar located in the OpenOffice repository. 
Of course it would be better to include such a code in Open Office release.

regards
Vincent
Comment 12 Marcus 2017-05-20 11:31:21 UTC
Reset assigne to the default "issues@openoffice.apache.org".