Apache OpenOffice (AOO) Bugzilla – Issue 70428
Add new java methods to start OpenOffice.org even if the jar files are not in the installation directory.
Last modified: 2017-05-20 11:31:21 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.
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...
.
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
What it the state of this bug? (Is the work in progress?) Do you need some help?
@helloworld82: No, not yet started. (Of course, you are welcome to send in patches.)
Created attachment 42245 [details] Path for the bootstrap method
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
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>.
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.
See related issue 66050.
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
Reset assigne to the default "issues@openoffice.apache.org".