Issue 85804 - [MWEx] File -> Send -> To Mediawiki fails with Exception
Summary: [MWEx] File -> Send -> To Mediawiki fails with Exception
Status: CLOSED FIXED
Alias: None
Product: Writer
Classification: Application
Component: configuration (show other issues)
Version: current
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: rene
QA Contact: issues@sw
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-01 20:10 UTC by rene
Modified: 2017-05-20 11:42 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description rene 2008-02-01 20:10:23 UTC 
File -> Send -> To Mediawiki (with a mediawiki.oxt registered in an OOo 2.4 )
gives the following Exception on the console when choosed.

com.sun.star.uno.RuntimeException: 
   at com.sun.star.bridges.jni_uno.JNI_proxy.dispatch_call(JNI_proxy.java:143)
   at com.sun.star.bridges.jni_uno.JNI_proxy.invoke(JNI_proxy.java:183)
   at $Proxy22.createDialogWithHandler(Unknown Source:0)
   at com.sun.star.wiki.WikiDialog.<init>(Unknown Source)
   at com.sun.star.wiki.WikiPropDialog.<init>(Unknown Source)
   at com.sun.star.wiki.WikiEditorImpl.sendArticle(Unknown Source)
   at com.sun.star.wiki.WikiEditorImpl.dispatch(Unknown Source)

Reproducable with gcj, Sun 1.5 and Sun 1.6 as JVMs. My system is x86_64, no idea
yet whether that matters.
Comment 1 mikhail.voytenko 2008-02-04 09:15:33 UTC 
I can not reproduce the problem.
Please be aware that it could be a result of intermediate state of the source
code, or an incompatible change in java code or in configuration. Please try to
rebuild the class from the scratch and to remove the office user folder with the
old extension installations.

If the problem is still reproducible after that please let me know which exactly
version of the OOo is used.
Comment 2 mikhail.voytenko 2008-02-04 09:17:00 UTC 
Sorry, a typo, by "rebuild the class from the scratch" I mean rebuilding of the
project.
Comment 3 rene 2008-02-04 09:35:12 UTC 
did that. Unregistered the extension, rebuild swext from a clean, up-to-date co
(after yours and my commit today). Still happens.

x86_64, all JVMs.

"and to remove the office user folder with the old extension installations."

Not possible, I of course register it --shared :)
Comment 4 mikhail.voytenko 2008-02-05 08:35:13 UTC 
According to the comment from RENE in issue 85805, the extension tabpage in the
Tools/Options dialog is also empty. There seems to be a general problem with
basic dialogs usage in the described in this bug installation.

Currently there seems to be at least two "special" things in the installation:
x86_64 build and extension installation in the shared folder.
Comment 5 rene 2008-02-08 12:06:40 UTC 
FTR --shared vs. not-shared makes no difference
Comment 6 noel.power 2008-04-30 14:23:29 UTC 
rene, can you QA this issue, its fixed ( via re-generated cws-npower9.diff ), I
will also add to the ooobuild 2.4 branch 

background info about the problem

this is an oobuild problem where there was early integration of npower9 ( which
refactors some aspects of the dialog code )
The problem here is with uno bindings, it seems that recent builds ( note I am
not sure how recent ) create those bindings with 
ScriptType = "UNO" & ScriptCode = "vnd.sun.star.UNO:xxxx"

unfortunately I tested with the DialogComponent.oxt from the DevGuide where the
bindings are of the form 
ScriptType = "Script" & ScriptCode = "vnd.sun.star.UNO:xxxx"

the refactored code looks at the ScriptType and ScriptCode ( and wasn't aware of
the ScriptType == "UNO" ) hence the breakage

fixed in npower9 now
Comment 7 rene 2008-05-01 15:20:38 UTC 
then you should set it to FIXED ;-)
Comment 8 rene 2008-05-01 15:21:29 UTC 
VERIFIED that it now works. Thanks.