Apache OpenOffice (AOO) Bugzilla – Issue 95162
Java extensions cannot be installed in some environments
Last modified: 2008-11-13 09:05:42 UTC
In some Java installs (notably in Windows XP SP3), Java UNO services cannot be registered. The message is unhelpful (the issue 75316 might make it more intelligible): (com.sun.star.registry.CannotRegisterImplementationException) {{Message="",Context=com.sun.star.uno.XInterface) @0}} It affects all Java extensions on such machines. See for example reports at: http://extensions.services.openoffice.org/project/reportdesign http://extensions.services.openoffice.org/project/aletras Some people reported that disabling all Java versions older than 6 might help but in tests, it turned out to be false. Java works on affected machines but OOo cannot register any Java services. Note: it's hard to replicate but I have at least ten reports from different people trying to install LanguageTool in OOo 3.0 about this, so please don't close it with WORKSFORME. It also works for me - there just must be some special conditions that trigger the bug.
@jsk: Could you try to reproduce this?
FYI, the link to other reports about it with LT 0.9.4 is here: http://sourceforge.net/tracker/?func=detail&atid=655717&aid=2064120&group_id=110216
Found the reason: the bug appears when the username contains non-ASCII characters (such as Russian or Polish characters). The admin-mode install works fine in such cases (most of the time), as admin accounts usually have shorter names without such chars. Raising the priority as now it's fixable and severe: you cannot use any user-mode installed Java extension in certain user accounts.
I am the one who reported the bug: http://sourceforge.net/tracker/?func=detail&atid=655717&aid=2064120&group_id=110216 Milek is right. My username contains a non-ASCII character. But when I logged as Administrator (Windows), I can install the Java extension LanguageTool.
Confirmed, but i fail with a com.sun.star.deployment.DeploymentException, stating that i'm working on a read-only context. Making this a stopper for 3.0.1
Created attachment 57543 [details] Exception thrown when installing to userdir with non-ascii characters
Not yet confirmed for Unixish platforms, so i'm setting OS to Windows/all for now.
milek->jsk: According to a report on the extension website, this happened already in 2.3.1 on OpenSuse, so this might affect Unixish platforms as well (though I'm not sure if all of them allow non-ASCII usernames): http://extensions.services.openoffice.org/project/aletras I will try to create such an account on my Suse box today and test it.
It turns out that by default Linux systems disallow non-ASCII characters in user names. For example, KDE by default doesn't understand non-ASCII usernames.
Hi Milek, while trying to reproduce this issue i ran into another problem which i now filed as issue 95628. I discussed this problem with HRO, one of our core system geeks and he pointed out that your issue is most likely not related to characters being outside the ASCII table (which made me fail in reproducing this issue) but that the characters are outside the *ANSI* Table - which makes a slight difference that i was not aware of. However, until now i've been unable to reproduce the problem. I always run into issue 95628 before even getting to the exception you reported. Could you please provide me with following information so i can build a 1:1 scenario: - Which locale was the office installed under (en_US?) - Which locale does is your user have (pl_PL?) Or do you use UTF-8 locales?
VICTORY! I got it, apparently my name is good enough for an exception as well - the simplest solution is always the best. @JL: Reproduction is simple - Install office as local administrator for all users - Create a local user named "Jörg" - Switch to the new user - Start the office - Install LanguageTool -> Exception Note that apparently not all extensions are affected, really use the Language Tool (0.9.4). So this issue appears for a very common use case so priority and target remain ok. You cannot use Linux for reproduction as you are not allowed to create a user with such a name.
Created attachment 57569 [details] Found it.
milek->jsk: - Which locale was the office installed under (en_US?) pl_PL (but we had reports from fr_FR as well) - Which locale does is your user have (pl_PL?) pl_PL - but in Windows, we have two different codepages, cp852 (IBM Latin2), which is OEM, and CP1250, which is normally called ANSI in most programs but is actually not ANSI at all. Don't ask me who could have created such a conceptual mess. Now, I have a special account on my box called "Wiesław Żółć" created normally in Windows - and this account is used for replicating this bug. Probably TCM sanity tests should mention running OpenOffice.org on "Wiesław Żółć" account. BTW, all and only Java extensions are affected.
The problem occurs not only at installation. I desactivated LanguageTool with my non-ASCII username. -> OK. If I try to reactivate it, I get also the following message: (com.sun.star.registry.CannotRegisterImplementationException) {{Message="",Context=com.sun.star.uno.XInterface) @0}}
I don't know if there is a relation, but for the first time, after this test, OOo refused to quit. The red-right-top button or the menu command performed no action. I had to kill the processes.
An easier way to reproduce is to create a local folder, for example: D:\Jörg and then edit the bootstrap.ini: UserInstallation=file:///d:/J%C3%B6rg The actual problen is in jurt, method com.sun.star.comp.loader.RegistrationClassFinder.find If the class is to be loaded with an URLClassLoader then this fails, because of the location URL which uses UTF8, but Java expects something different here.
Created attachment 57621 [details] partial fix
[Testing with LanguageTool-0.9.4.oxt from <http://extensions.services.openoffice.org>.] The attached jurt.patch adds the missing com.sun.star.uri.ExternalUriReferenceTranslator.translateToExternal call to com.sun.star.comp.loader.JavaLoader. However, with this partial fix, extension installation still fails due to jar.openStream() at ridljar/source/unoloader/com/sun/star/lib/unoloader/UnoClassLoader.java l. 193 now throwing a java.lang.IllegalArgumentException (even though the jar.toString() = "file:/D:/J%F6rg/user/uno_packages/cache/uno_packages/726.tmp_/LanguageTool-0.9.4.oxt/LanguageTool.uno.jar" looks good). This needs further evaluation. I assume the error is present since the class path cleanup in OOo 2.3. I have no time to fix this for OOo 3.0.1, hence move it to OOo 3.1.
milek->sb: this is a known Java bug, see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6522294 Try this (this is a recommended workaround): JarInputStream s = new JarInputStream(new URI(jar).toASCIIString().openStream());
milek->sb: I managed to fix one half of the remaining bug. It's enough to add the following to getJarMainAttributes(URL jar): JarInputStream s = new JarInputStream(new URL( URLDecoder.decode(jar.toString(), System.getProperty("sun.jnu.encoding", "UTF-8"))).openStream()); But immediately after it I get IllegalArgumentException with cl2.loadClass(name) in RegistrationClassFinder. I instrumented the exception and here's the stack: java.lang.IllegalArgumentException sun.net.www.ParseUtil.decode(Unknown Source) sun.misc.URLClassPath$JarLoader.<init>(Unknown Source) sun.misc.URLClassPath$3.run(Unknown Source) java.security.AccessController.doPrivileged(Native Method) sun.misc.URLClassPath.getLoader(Unknown Source) sun.misc.URLClassPath.getLoader(Unknown Source) sun.misc.URLClassPath.getResource(Unknown Source) java.net.URLClassLoader$1.run(Unknown Source) java.security.AccessController.doPrivileged(Native Method) java.net.URLClassLoader.findClass(Unknown Source) java.lang.ClassLoader.loadClass(Unknown Source) java.lang.ClassLoader.loadClass(Unknown Source) java.net.FactoryURLClassLoader.loadClass(Unknown Source) java.lang.ClassLoader.loadClass(Unknown Source) com.sun.star.comp.loader.RegistrationClassFinder.find(RegistrationClassFinder.java:90) com.sun.star.comp.loader.JavaLoader.writeRegistryInfo(JavaLoader.java:433) I tried decoding the URL the same way as above for class loader constructor but it didn't work (the version with UTF-8 as-is, UTF-8 percent-encoded and UTF-16 failed). If anyone has an idea what is the proper representation of the URL for loadClass (that is, for UnoClassLoader, which is in turn only using the inherited method from URLFactoryClassLoader, as far as I remember), I'd appreciate it. Note that there is some strange problem here: the string produced by explicitly calling sun.net.www.ParseUtil.decode on url.toString() is the same as url.toString() and there is no error in that case. So the problem is probably not just with ParseUtil.decode(). Any pointers, anyone?
I found out the reason why the second IllegalArgumentException appears. The first fix (with URLDecoder) works fine for all extensions that contain jar files that don't have anything on the classpath (like A Letras from the Extensions website). In case there is some non-empty classpath, ParseUtil.decode() gets crazy. I tried a very brutal fix (removing classpath from attr in RegistrationClassFinder) but it didn't help at all with registering a class.
cc HRO
My attached jurt.patch of course is nonsense. It appears I had completely forgotten about issue 93769. *** This issue has been marked as a duplicate of 93769 ***
.