Problem while upgrading from OOo 3.0.0 to Ooo 3.0.1 with a GC extension

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem while upgrading from OOo 3.0.0 to Ooo 3.0.1 with a GC extension

William Colen
Hi all,

LanguageTool developers already pointed an issue that one must de-install
the Grammar Checker extension compatible with OOo 3.0.0 before upgrading to
OOo 3.0.1. I found the same issue with Cogroo. It looks like we can't remove
the extension anymore in this case.
Does anybody know a user friendly procedure that we could point to the users
if they have this problem? I'm sure it will happen a lot and they will not
be happy with loosing all their configurations and extensions.

Thank you
William

PS: Thank you Thomas and Marcin. I could fix Cogroo, it was an
initialization problem. I notice that Cogroo was not singleton. That is what
happens when one start doing things without studding the homework!
Reply | Threaded
Open this post in threaded view
|

Re: Problem while upgrading from OOo 3.0.0 to Ooo 3.0.1 with a GC extension

Marcin Miłkowski
Hi William,

I have just made a wiki page with instructions for users:

http://languagetool.wikidot.com/removing-languagetool-0-9-5-from-openoffice-3-0-1

But this is not very user-friendly as data loss seems to be inevitable in many cases. I have no easy procedure for saving unaffected settings and templates.

And yes, I should have mentioned that using a singleton is really important. Equally important is to make the main checking method synchronized, otherwise your checker might be not ready with previous check and get another query. This results with incorrect behavior.

Regards
Marcin

Dnia 28 stycznia 2009 11:47 William Colen <[hidden email]> napisał(a):

> Hi all,
>
> LanguageTool developers already pointed an issue that one must de-install
> the Grammar Checker extension compatible with OOo 3.0.0 before upgrading to
> OOo 3.0.1. I found the same issue with Cogroo. It looks like we can't remove
> the extension anymore in this case.
> Does anybody know a user friendly procedure that we could point to the users
> if they have this problem? I'm sure it will happen a lot and they will not
> be happy with loosing all their configurations and extensions.
>
> Thank you
> William
>
> PS: Thank you Thomas and Marcin. I could fix Cogroo, it was an
> initialization problem. I notice that Cogroo was not singleton. That is what
> happens when one start doing things without studding the homework!
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Problem while upgrading from OOo 3.0.0 to Ooo 3.0.1 with a GC extension

Mathias Bauer
Hi,

can you explain more deeply what the exact problem is? Is it a general
problem in our extensions infrastructure?

Regards,
Mathias

Marcin Miłkowski wrote:

> Hi William,
>
> I have just made a wiki page with instructions for users:
>
> http://languagetool.wikidot.com/removing-languagetool-0-9-5-from-openoffice-3-0-1
>
> But this is not very user-friendly as data loss seems to be inevitable in many cases. I have no easy procedure for saving unaffected settings and templates.
>
> And yes, I should have mentioned that using a singleton is really important. Equally important is to make the main checking method synchronized, otherwise your checker might be not ready with previous check and get another query. This results with incorrect behavior.
>
> Regards
> Marcin
>
> Dnia 28 stycznia 2009 11:47 William Colen <[hidden email]> napisał(a):
>
>> Hi all,
>>
>> LanguageTool developers already pointed an issue that one must de-install
>> the Grammar Checker extension compatible with OOo 3.0.0 before upgrading to
>> OOo 3.0.1. I found the same issue with Cogroo. It looks like we can't remove
>> the extension anymore in this case.
>> Does anybody know a user friendly procedure that we could point to the users
>> if they have this problem? I'm sure it will happen a lot and they will not
>> be happy with loosing all their configurations and extensions.
>>
>> Thank you
>> William
>>
>> PS: Thank you Thomas and Marcin. I could fix Cogroo, it was an
>> initialization problem. I notice that Cogroo was not singleton. That is what
>> happens when one start doing things without studding the homework!
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[hidden email]".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Problem while upgrading from OOo 3.0.0 to Ooo 3.0.1with a GC extension

Marcin Miłkowski
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


Dnia 28 stycznia 2009 12:49 Mathias Bauer <[hidden email]> napisał(a):

> Hi,
>
> can you explain more deeply what the exact problem is? Is it a general
> problem in our extensions infrastructure?
>
> Regards,
> Mathias
>
> Marcin Miłkowski wrote:
>
> > Hi William,
> >
> > I have just made a wiki page with instructions for users:
> >
> > http://languagetool.wikidot.com/removing-languagetool-0-9-5-from-openoffice-3-0-1
> >
> > But this is not very user-friendly as data loss seems to be inevitable in many cases. I have no easy procedure for saving unaffected settings and templates.
> >
> > And yes, I should have mentioned that using a singleton is really important. Equally important is to make the main checking method synchronized, otherwise your checker might be not ready with previous check and get another query. This results with incorrect behavior.
> >
> > Regards
> > Marcin
> >
> > Dnia 28 stycznia 2009 11:47 William Colen  napisał(a):
> >
> >> Hi all,
> >>
> >> LanguageTool developers already pointed an issue that one must de-install
> >> the Grammar Checker extension compatible with OOo 3.0.0 before upgrading to
> >> OOo 3.0.1. I found the same issue with Cogroo. It looks like we can't remove
> >> the extension anymore in this case.
> >> Does anybody know a user friendly procedure that we could point to the users
> >> if they have this problem? I'm sure it will happen a lot and they will not
> >> be happy with loosing all their configurations and extensions.
> >>
> >> Thank you
> >> William
> >>
> >> PS: Thank you Thomas and Marcin. I could fix Cogroo, it was an
> >> initialization problem. I notice that Cogroo was not singleton. That is what
> >> happens when one start doing things without studding the homework!
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> --
> Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
> OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
> Please don't reply to "[hidden email]".
> I use it for the OOo lists and only rarely read other mails sent to it.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Problem while upgrading from OOo 3.0.0 to Ooo 3.0.1with a GC extension

thomas.lange
In reply to this post by William Colen

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...

And in respect to updating an extension: if the extension identifier
matches and a new version is found the old version should be disabled
(and removed on next start) while the new version is to be enabled with
the next office start. Of course a new version of the extension must
always match the current API of the Office.
I fail to see why this should not work.


TL->SB,JL: Maybe you like to add some comment from a perspective with
more insight to the specific problems. :-)
(for more details on the actual problem see below or check the
lingucomponent list)


Regards,
Thomas



>
> Dnia 28 stycznia 2009 12:49 Mathias Bauer <[hidden email]> napisał(a):
>
>> Hi,
>>
>> can you explain more deeply what the exact problem is? Is it a general
>> problem in our extensions infrastructure?
>>
>> Regards,
>> Mathias
>>
>> Marcin Miłkowski wrote:
>>
>> > Hi William,
>> >
>> > I have just made a wiki page with instructions for users:
>> >
>> > http://languagetool.wikidot.com/removing-languagetool-0-9-5-from-openoffice-3-0-1
>> >
>> > But this is not very user-friendly as data loss seems to be inevitable in many cases. I have no easy procedure for saving unaffected settings and templates.
>> >
>> > And yes, I should have mentioned that using a singleton is really important. Equally important is to make the main checking method synchronized, otherwise your checker might be not ready with previous check and get another query. This results with incorrect behavior.
>> >
>> > Regards
>> > Marcin
>> >
>> > Dnia 28 stycznia 2009 11:47 William Colen  napisał(a):
>> >
>> >> Hi all,
>> >>
>> >> LanguageTool developers already pointed an issue that one must de-install
>> >> the Grammar Checker extension compatible with OOo 3.0.0 before upgrading to
>> >> OOo 3.0.1. I found the same issue with Cogroo. It looks like we can't remove
>> >> the extension anymore in this case.
>> >> Does anybody know a user friendly procedure that we could point to the users
>> >> if they have this problem? I'm sure it will happen a lot and they will not
>> >> be happy with loosing all their configurations and extensions.
>> >>
>> >> Thank you
>> >> William
>> >>
>> >> PS: Thank you Thomas and Marcin. I could fix Cogroo, it was an
>> >> initialization problem. I notice that Cogroo was not singleton. That is what
>> >> happens when one start doing things without studding the homework!
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>>
>>
>> --
>> Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
>> OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
>> Please don't reply to "[hidden email]".
>> I use it for the OOo lists and only rarely read other mails sent to it.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Problem while upgrading from OOo 3.0.0 to Ooo 3.0.1with a GC extension

Caio Tiago Oliveira-2
Thomas Lange - Sun Germany - ham02 - Hamburg, 28-01-2009 09:31:

> 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...

They disable the extensions based on the maximum version defined. The
maximum version is defined within a range where Mozilla assures it won't
break anything within extensions.
If some bug is introduced somewhere and is not found until the time of
the release, the extension will run and behave incorrectly.

They release another version to fix the regression. But in the meantime,
the user have to disable the extension manually.
In this case, they have an option to launch the application without any
kind of extension or theme loading, so it's guaranteed it will startup
properly.

Then they enforce the developer to test and update the maximum version
field - compatible versions, more specifically. They allow the developer
to change it within the site they use to manage extensions - no need
from the developer to upload it again. Also the extensions are checked
for updates and updated automatically - even tough it's just to update
the compatible versions field.



So... comparing with Mozilla, they grant the possibility to
uninstall/upgrade by using the compatible versions field and enforcing
the update.
They require not bogus version numbers on the extensions hosted on
addons.mozilla.org.
Of course this solution won't work if someone uses "3.*", or "4.*" or
"10.*". But we should make the extension developers aware of the
possibility of API changes and make them use right value.

The other part of the solution is a politic of API changes. Mozilla does
not change its existing API within a major version. Most API are frozen
and only will be allowed to change within Gecko branch 2 (Firefox 4 or
possible Firefox 5).

If we are allowed to make incompatible changes to the API within "3.*",
we should allow the maximum version field to specify at least the minor
version. So the extensions would have to be tested and updated for 3.2,
3.3, etc.
No extension would be allowed to tell it's compatible with every 3.x
release.
This way, we wouldn't have such incompatibilities, except by the
extension's developer fault - by not testing properly and updating the
field.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Problem while upgrading from OOo 3.0.0 to Ooo 3.0.1with a GC extension

Joachim Lingner - Sun Germany Software Engineer - ham02 - Hamburg
In reply to this post by William Colen
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.

>
> And in respect to updating an extension: if the extension identifier
> matches and a new version is found the old version should be disabled
> (and removed on next start) while the new version is to be enabled with
> the next office start. Of course a new version of the extension must
> always match the current API of the Office.
> I fail to see why this should not work.

If you install an extensions and there is already an extension with the
same id installed, then the installad one is first removed before the
other is installed.


Joachim


>
>
> TL->SB,JL: Maybe you like to add some comment from a perspective with
> more insight to the specific problems. :-)
> (for more details on the actual problem see below or check the
> lingucomponent list)
>
>
> Regards,
> Thomas
>
>
>
>> Dnia 28 stycznia 2009 12:49 Mathias Bauer <[hidden email]> napisał(a):
>>
>>> Hi,
>>>
>>> can you explain more deeply what the exact problem is? Is it a general
>>> problem in our extensions infrastructure?
>>>
>>> Regards,
>>> Mathias
>>>
>>> Marcin Miłkowski wrote:
>>>
>>>> Hi William,
>>>>
>>>> I have just made a wiki page with instructions for users:
>>>>
>>>> http://languagetool.wikidot.com/removing-languagetool-0-9-5-from-openoffice-3-0-1
>>>>
>>>> But this is not very user-friendly as data loss seems to be inevitable in many cases. I have no easy procedure for saving unaffected settings and templates.
>>>>
>>>> And yes, I should have mentioned that using a singleton is really important. Equally important is to make the main checking method synchronized, otherwise your checker might be not ready with previous check and get another query. This results with incorrect behavior.
>>>>
>>>> Regards
>>>> Marcin
>>>>
>>>> Dnia 28 stycznia 2009 11:47 William Colen  napisał(a):
>>>>
>>>>> Hi all,
>>>>>
>>>>> LanguageTool developers already pointed an issue that one must de-install
>>>>> the Grammar Checker extension compatible with OOo 3.0.0 before upgrading to
>>>>> OOo 3.0.1. I found the same issue with Cogroo. It looks like we can't remove
>>>>> the extension anymore in this case.
>>>>> Does anybody know a user friendly procedure that we could point to the users
>>>>> if they have this problem? I'm sure it will happen a lot and they will not
>>>>> be happy with loosing all their configurations and extensions.
>>>>>
>>>>> Thank you
>>>>> William
>>>>>
>>>>> PS: Thank you Thomas and Marcin. I could fix Cogroo, it was an
>>>>> initialization problem. I notice that Cogroo was not singleton. That is what
>>>>> happens when one start doing things without studding the homework!
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>> --
>>> Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
>>> OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
>>> Please don't reply to "[hidden email]".
>>> I use it for the OOo lists and only rarely read other mails sent to it.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Problem while upgrading from OOo 3.0.0 to Ooo 3.0.1with a GC extension

Mathias Bauer
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.

Ciao,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[hidden email]".
I use it for the OOo lists and only rarely read other mails sent to it.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Problem while upgrading from OOo 3.0.0 to Ooo 3.0.1with a GC extension

Marcin Miłkowski
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Problem while upgrading from OOo 3.0.0 to Ooo 3.0.1with a GC extension

William Colen
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Problem while upgrading from OOo 3.0.0 to Ooo 3.0.1with a GC extension

Marcin Miłkowski
Hi,

that's not the best news we could hear :(

I don't exactly remember which jar contained the XGrammarChecker class but you could try copying this into Cogroo directory while replacing the main Cogroo jar with a jar that contains the classpath setting to search for this jar in the current directory. So basically the script should copy two files. And then try unopkg... I guess this could be scripted for Windows and Mac & Unices (one batch file and one shell script). I don't have access to my development machine so I cannot experiment right now, so I'd be grateful if you could :)

The script could first call unopkg to see if LT or Cogroo is left over, and only then do the dirty job.

Regards
Marcin


Dnia 29 stycznia 2009 2:33 William Colen <[hidden email]> napisał(a):

> 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  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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Problem while upgrading from OOo 3.0.0 to Ooo 3.0.1with a GC extension

William Colen
I can't do that today also. I'll do it tomorrow.

Thank you!
William

On Thu, Jan 29, 2009 at 11:19 AM, Marcin Miłkowski <[hidden email]> wrote:

> Hi,
>
> that's not the best news we could hear :(
>
> I don't exactly remember which jar contained the XGrammarChecker class but
> you could try copying this into Cogroo directory while replacing the main
> Cogroo jar with a jar that contains the classpath setting to search for this
> jar in the current directory. So basically the script should copy two files.
> And then try unopkg... I guess this could be scripted for Windows and Mac &
> Unices (one batch file and one shell script). I don't have access to my
> development machine so I cannot experiment right now, so I'd be grateful if
> you could :)
>
> The script could first call unopkg to see if LT or Cogroo is left over, and
> only then do the dirty job.
>
> Regards
> Marcin
>
>
> Dnia 29 stycznia 2009 2:33 William Colen <[hidden email]>
> napisał(a):
>
> > 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  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: [hidden email]
> > > For additional commands, e-mail:
> [hidden email]
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Problem while upgrading from OOo 3.0.0 to Ooo 3.0.1with a GC extension

William Colen
Marcin
Good news! I could try it today. Instead of recompile things, I tried to
override the old jar with the new one that don't require the XGrammarChecker
class. It was possible to remove using unopkg.

I'm going to try a script to uninstall it in Windows. I can try it with LT
also. Unfortunately I don't know how to write shell scripts.

Regards
William


2009/1/29 William Colen <[hidden email]>

> I can't do that today also. I'll do it tomorrow.
>
> Thank you!
> William
>
> On Thu, Jan 29, 2009 at 11:19 AM, Marcin Miłkowski <[hidden email]> wrote:
>
>> Hi,
>>
>> that's not the best news we could hear :(
>>
>> I don't exactly remember which jar contained the XGrammarChecker class but
>> you could try copying this into Cogroo directory while replacing the main
>> Cogroo jar with a jar that contains the classpath setting to search for this
>> jar in the current directory. So basically the script should copy two files.
>> And then try unopkg... I guess this could be scripted for Windows and Mac &
>> Unices (one batch file and one shell script). I don't have access to my
>> development machine so I cannot experiment right now, so I'd be grateful if
>> you could :)
>>
>> The script could first call unopkg to see if LT or Cogroo is left over,
>> and only then do the dirty job.
>>
>> Regards
>> Marcin
>>
>>
>> Dnia 29 stycznia 2009 2:33 William Colen <[hidden email]>
>> napisał(a):
>>
>> > 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  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: [hidden email]
>> > > For additional commands, e-mail:
>> [hidden email]
>> > >
>> > >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Problem while upgrading from OOo 3.0.0 to Ooo 3.0.1with a GC extension

William Colen
Hi,

Alain M., from the OOo Brazilian community, suggested the following solution:

1. Remove OOo 3.0.1
2. Install OOo 3.0.0
3. Remove the GC extension
4. Install OOo 3.0.1
5. Install the new GC extension

I tried it with Windows XP and it works fine.

Regards,
William



2009/1/29 William Colen <[hidden email]>:

> Marcin
> Good news! I could try it today. Instead of recompile things, I tried to
> override the old jar with the new one that don't require the XGrammarChecker
> class. It was possible to remove using unopkg.
> I'm going to try a script to uninstall it in Windows. I can try it with LT
> also. Unfortunately I don't know how to write shell scripts.
> Regards
> William
>
>
> 2009/1/29 William Colen <[hidden email]>
>>
>> I can't do that today also. I'll do it tomorrow.
>> Thank you!
>> William
>> On Thu, Jan 29, 2009 at 11:19 AM, Marcin Miłkowski <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> that's not the best news we could hear :(
>>>
>>> I don't exactly remember which jar contained the XGrammarChecker class
>>> but you could try copying this into Cogroo directory while replacing the
>>> main Cogroo jar with a jar that contains the classpath setting to search for
>>> this jar in the current directory. So basically the script should copy two
>>> files. And then try unopkg... I guess this could be scripted for Windows and
>>> Mac & Unices (one batch file and one shell script). I don't have access to
>>> my development machine so I cannot experiment right now, so I'd be grateful
>>> if you could :)
>>>
>>> The script could first call unopkg to see if LT or Cogroo is left over,
>>> and only then do the dirty job.
>>>
>>> Regards
>>> Marcin
>>>
>>>
>>> Dnia 29 stycznia 2009 2:33 William Colen <[hidden email]>
>>> napisał(a):
>>>
>>> > 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  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: [hidden email]
>>> > > For additional commands, e-mail:
>>> > > [hidden email]
>>> > >
>>> > >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Problem while upgrading from OOo 3.0.0 to Ooo 3.0.1with a GC extension

thomas.lange
In reply to this post by William Colen

Hi all,

William Colen wrote:

> Hi,
>
> Alain M., from the OOo Brazilian community, suggested the following solution:
>
> 1. Remove OOo 3.0.1
> 2. Install OOo 3.0.0
> 3. Remove the GC extension
> 4. Install OOo 3.0.1
> 5. Install the new GC extension


Actually it should be much easier.
For example if the GC extension was the only extension you downloaded
manually and it got installed as "For this user only", then going to the
folder with your user-settings for that OOo you should be able to find a
folder named "user/uno_packages" below that directory.
Now if you don't mind loosing all all your extensions that got installed
as "for this user only" then you can simply remove the "uno_packages"
folder to get rid of all those extensions.

Similar means can be applied to shared installed extensions but by
simply removing "uno_packages" folder in the share layer you will also
loose all dictionary extensions (and others) that came with OOo and you
would have to install them manually again.

If the above solution is to your taste is up to you.

Regards,
Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]