Marcin,

I tried that but without success. First I tried with Cogroo and it failed.
To make sure it wasn't something on Cogroo side I tried with LT and it also
failed :(

1. Installed OOo 3.0.0
2. Installed LT 0.9.5
3. Installed OOo 3.0.1

See the unopkg output:

C:\Program Files\OpenOffice.org 3\program>unopkg remove
org.openoffice.languaget
ool.oxt

ERROR: [jni_uno bridge error] UNO calling Java method writeRegistryInfo:
non-UNO
 exception occurred: java.lang.NoClassDefFoundError:
com/sun/star/linguistic2/XG
rammarChecker
java stack trace:
java.lang.NoClassDefFoundError: com/sun/star/linguistic2/XGrammarChecker
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.access$000(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.net.FactoryURLClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at
com.sun.star.comp.loader.RegistrationClassFinder.find(RegistrationCla
ssFinder.java:67)
        at
com.sun.star.comp.loader.JavaLoader.writeRegistryInfo(JavaLoader.java
:433)
Caused by: java.lang.ClassNotFoundException:
com.sun.star.linguistic2.XGrammarCh
ecker
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClassInternal(Unknown Source)
        ... 14 more


Thanks
William

On Wed, Jan 28, 2009 at 8:55 PM, Marcin Miłkowski <[email protected]> wrote:

> Mathias Bauer pisze:
>
>  Joachim Lingner wrote:
>>
>>  Thomas Lange - Sun Germany - ham02 - Hamburg schrieb:
>>>
>>>> Hi,
>>>>
>>>> Marcin Miłkowski wrote:
>>>>
>>>>  Hi,
>>>>>
>>>>> the problem is that the Java API has changed. So our extension that
>>>>> used the old API cannot find classes in new jars, and because of this fact
>>>>> you cannot uninstall it via the Extension Manager. Moreover, you cannot 
>>>>> even
>>>>> specify the maximum allowed version for an extension (we wanted to do so),
>>>>> as this was introduced in 3.1, so it doesn't work for 3.0.0.
>>>>>
>>>>> Probably another workaround would be to manually copy the old jar to
>>>>> the extension directory and add it to the classpath, then use unopkg to
>>>>> remove the extension. In Linux, this is probably easily scriptable. In
>>>>> Windows, I'm not so sure... If you have any other suggestions, we will be
>>>>> grateful.
>>>>>
>>>>> This is a limitation of the Extension infrastructure, actually. The
>>>>> required maximum version feature is already implemented so this is already
>>>>> fixed for future versions of OOo.
>>>>>
>>>>> Regards
>>>>> Marcin
>>>>>
>>>>>
>>>> I do not consider the implementation of a maximum version to be a fix
>>>> for not being able to uninstall/upgrade extensions, even though the API
>>>> incompatibility has happened.
>>>>
>>>> If it is about updating the Office: If on the next start, after the
>>>> office update, incompatible extensions are found those should be
>>>> automatically disabled before the office gets started. Or at least they
>>>> should be disabled and then the Office automatically restarted once more
>>>> if necessary.
>>>> Firefox and Thunderbird for example seem to be able to do that...
>>>>
>>> Yup. Missing feature. Although, if the removal fails because of the Java
>>> problem, then certainly disabling the extension would fail as well.
>>>
>>
>> This is another good argument for one of my feature wishes: please allow
>> the registration of binaries to be based on registry files (preferable
>> human readable ones), don't require them to be executable or loadable
>> for registration or deregistration. It would also be a performance win
>> for the extension manager.
>>
>> The same works pretty well for COM components on Windows: you can call
>> regsvr32.exe either on a libarary or on a reg file.
>>
>
> Daniel Naber has just found that unopkg can fix the problem :)
>
> So basically you can do it like this:
>
> unopkg remove org.openoffice.languagetool.oxt
>
> But it's clearly a defect that the Extension Manager is unable to do so.
>
> Regards
> Marcin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to