To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=70428
------- Additional comments from [EMAIL PROTECTED] Fri Jan 19 07:53:13 -0800 2007 ------- 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. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- 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]
