I forgot to tell I am using openoffice in french

I cannot reproduce it on Solaris SUNRay with OOo 3.0

@MAV: any comment about the console error message?

The message appears immediatley after clicking ok,  the access to my mediawiki 
or fr.mediawiki.org needs a few "visible" access time .

After looking at my webserver logs, it seems that it does not target my 
192.168.1.242 url at all , no trace of the requests ... either using the dns  
machine name is not targeted.
 
I made a dump on my net interface :
tcpdump -i eth1 80 : nothing goes out ....

Do you use proxy for connection? If yes, could you please check which value is
set in "Tools/Options/Internet/Proxy" tab page.

I had already checked for proxy settings : None 

I have direct access to my machine,  THERE IS NO PROXY , my webserver and 
mediawiki are running on my machine, and ooffice also.

However, I set it up another way :
if I setup proxy to manual (http proxy fields left blank) and disable proxy for 
192.168.1.242; now I can use 
the extension to connect to http://192.168.1.242/mediawiki

THERE IS A PROBLEM WITH THE PROXY SETTINGS USAGE !!! I DO NOT HAVE ANY PROXY !

I have already heard that there are problems on some linux installations.
Unfortunately there is still no known way to reproduce the problem. Anyway,
thanks a lot for the detailed explanation, it looks like setting the empty proxy
explicitly workarounds the system problem in your case.

@MAV: so what do we do? Do I close as WFM or do you want to work on it?

unfortunately, it does not ... and I think this will not be a standalone case .

Because the proxy problems affect the Send to mediawiki function , below is the 
result.

There are some possible reasons :
1) The first time I am launching ooffice the http proxy port field is empty , 
if you convert an empty string to int, you have the  following mistake message :
com.sun.star.lang.IllegalArgumentException: The Argument did not hold the 
proper type 
2) If I set up a proxy field (http and port) and reset it later , unfortunately 
the port field does not get empty again, but filled with 0 value....(Do we need 
to fill another bug report for this issue?)
3) another issue with a xslt transformation to convert it to mediawiki has 
appeared 



com.sun.star.lang.IllegalArgumentException: The Argument did not hold the 
proper type
	at com.sun.star.uno.AnyConverter.convertSimple(AnyConverter.java:540)
	at com.sun.star.uno.AnyConverter.toInt(AnyConverter.java:224)
	at com.sun.star.wiki.Helper.SetConfigurationProxy(Unknown Source)
	at com.sun.star.wiki.Helper.ExecuteMethod(Unknown Source)
	at com.sun.star.wiki.Helper.Login(Unknown Source)
	at com.sun.star.wiki.WikiArticle.Login(Unknown Source)
	at com.sun.star.wiki.WikiArticle.<init>(Unknown Source)
	at com.sun.star.wiki.WikiEditorImpl.SendArticleImpl(Unknown Source)
	at com.sun.star.wiki.WikiPropDialog$1.run(Unknown Source)
Nov 18, 2008 2:12:01 PM org.apache.commons.httpclient.HttpMethodBase 
getResponseBody
WARNING: Going to buffer response body of large or unknown size. Using 
getResponseBodyAsStream instead is recommended.
com.sun.star.lang.IllegalArgumentException: The Argument did not hold the 
proper type
	at com.sun.star.uno.AnyConverter.convertSimple(AnyConverter.java:540)
	at com.sun.star.uno.AnyConverter.toInt(AnyConverter.java:224)
	at com.sun.star.wiki.Helper.SetConfigurationProxy(Unknown Source)
	at com.sun.star.wiki.Helper.ExecuteMethod(Unknown Source)
	at com.sun.star.wiki.WikiEditSettingDialog.DoLogin(Unknown Source)
	at com.sun.star.wiki.WikiEditSettingDialog$1.run(Unknown Source)
Nov 18, 2008 2:12:22 PM org.apache.commons.httpclient.HttpMethodBase 
getResponseBody
WARNING: Going to buffer response body of large or unknown size. Using 
getResponseBodyAsStream instead is recommended.
com.sun.star.lang.IllegalArgumentException: The Argument did not hold the 
proper type
	at com.sun.star.uno.AnyConverter.convertSimple(AnyConverter.java:540)
	at com.sun.star.uno.AnyConverter.toInt(AnyConverter.java:224)
	at com.sun.star.wiki.Helper.SetConfigurationProxy(Unknown Source)
	at com.sun.star.wiki.Helper.ExecuteMethod(Unknown Source)
	at com.sun.star.wiki.Helper.Login(Unknown Source)
	at com.sun.star.wiki.WikiEditSettingDialog.DoLogin(Unknown Source)
	at com.sun.star.wiki.WikiEditSettingDialog$1.run(Unknown Source)
Nov 18, 2008 2:12:24 PM org.apache.commons.httpclient.HttpMethodBase 
getResponseBody
WARNING: Going to buffer response body of large or unknown size. Using 
getResponseBodyAsStream instead is recommended.
com.sun.star.lang.IllegalArgumentException: The Argument did not hold the 
proper type
	at com.sun.star.uno.AnyConverter.convertSimple(AnyConverter.java:540)
	at com.sun.star.uno.AnyConverter.toInt(AnyConverter.java:224)
	at com.sun.star.wiki.Helper.SetConfigurationProxy(Unknown Source)
	at com.sun.star.wiki.Helper.ExecuteMethod(Unknown Source)
	at com.sun.star.wiki.Helper.Login(Unknown Source)
	at com.sun.star.wiki.WikiArticle.Login(Unknown Source)
	at com.sun.star.wiki.WikiArticle.<init>(Unknown Source)
	at com.sun.star.wiki.WikiEditorImpl.SendArticleImpl(Unknown Source)
	at com.sun.star.wiki.WikiPropDialog$1.run(Unknown Source)
Nov 18, 2008 2:12:25 PM org.apache.commons.httpclient.HttpMethodBase 
getResponseBody
WARNING: Going to buffer response body of large or unknown size. Using 
getResponseBodyAsStream instead is recommended.
Nov 18, 2008 2:12:26 PM org.apache.commons.httpclient.HttpMethodBase 
getResponseBody
WARNING: Going to buffer response body of large or unknown size. Using 
getResponseBodyAsStream instead is recommended.
ERROR:  'file:///usr/lib/openoffice/basis3.0/share/xslt/wiki/odt2mediawiki.xsl: 
line 44: Circular variable/parameter reference in '[param
(CODE_TAB_REPLACEMENT), param(CODE_STYLES)]'.'
FATAL ERROR:  'Could not compile stylesheet'
com.sun.star.task.ErrorCodeIOException: 
	at com.sun.star.bridges.jni_uno.JNI_proxy.dispatch_call(Native Method)
	at com.sun.star.bridges.jni_uno.JNI_proxy.invoke(JNI_proxy.java:178)
	at $Proxy52.storeToURL(Unknown Source)
	at com.sun.star.wiki.WikiEditorImpl.SendArticleImpl(Unknown Source)
	at com.sun.star.wiki.WikiPropDialog$1.run(Unknown Source)

mav->es: I can not really investigate the problem until we can reproduce it. But
I have only now recognized that the stack refers to the GNU Java implementation.
That could be the explanation for the problem. Lets leave the bug open for a
while, I think.

mav->sancelot: The second stack looks indeed like a problem with export to the
wiki format. Please try to export the same document using Wiki export filter (
File/Export menu entry ).

mav->cmc: Do you have an idea whether GNU Java could be the cause of the problem?

my java machine uses openjdk 6
you can not reproduce the problem, but if you can provide me with an debug 
release of wiki extension that prints some debugging things I can try it.
Or provide me a basic java program that implements the httpclient methods 
only , I will be able running it.

Best Regards
steph

@MAV/CMC: as a see that the way of reproducing the problem slightly trespasses
my QA competence, may I dare to ask you to take over as owner? ;)
MAV? CMC?

I can see this (with openjdk), let me play around with it a bit

Created attachment 58088 [details]
this patch makes it work for me

cmc->mav: Does this patch keep it working in your environment. 

Afaics, 
a) A "", 0 as an empty proxy doesn't work for me. Sneaking a look at the
HostConfiguration.java from commons-httpclient gives me
aHostConfig.setProxyHost(null) as an alternative solution, and that does work
for me (http://wiki.services.openoffice.org/wiki/Cmc_wikipublisher_test)
b) If a manual proxy is set up, but proxy port left blank then I get a void Any
rather than an empty int Any, giving that "
"
com.sun.star.lang.IllegalArgumentException: The Argument did not hold the 
proper type
"
exception that sancelot mentions, so I worked around that as well
c) I kept entering the same url into the edit thing and got "duplicate entry"
stuff exceptions, so I decided to add in a fix for that as well at the end. But
the substantive bit is the first two sections of the patch.

The "system" proxy setting isn't sticking in the UI, but that's outside the
scope of this I guess.

mav->cmc: Thanks a lot for the investigation and the patch. I will integrate it
in one of the next wiki-extension related childworkspaces.

 how can I try the modified version ?!!!

mav->sancelot: You can either integrate the patch and build the extension
yourself ( it is in swext project ), or wait until the new version of the
extension is released.

??? Yes, I have already thinked about it, but unfortunately : 
There is no way downloading an archive of the cvs trunk throw web interface and 
I do not have a cvs access !!!
 
Best Regards
steph

The patch is integrated.

As I understood, there is no way to verify the scenario on our side currently. I
am setting the issue to verified by myself, since the fix is integrated in the cws. 

Created attachment 60475 [details]
the extension from mav46 cws. This is no official release, use at your own risk!

mav->cmc,sancelot: It would be nice if you had a chance to try the extension
with the GNU Java environment. It should work as expected, but please remember
that this is still an untested version and no official release. So close all the
important documents and be ready for all emergencies :)

By the way, the baseline of the extension has been changed in this cws to
OOo3.0, so please try it either in OOo3.0 or a later version.

Resetting to Fixed. Not verified yet.

.

That works for me at least

It's still not working for me.   I'm using the unofficial Wiki Publisher 1.1
posted here by mav yesterday on OpenOffice.org 3.0.1 on Ubuntu Jaunty.

http://www.openoffice.org/issues/show_bug.cgi?id=96279#desc23

Feb 26, 2009 4:30:09 PM org.apache.commons.httpclient.HttpMethodBase getResponseBody
WARNING: Going to buffer response body of large or unknown size. Using
getResponseBodyAsStream instead is recommended.
ERROR: 
'file:///home/merriam/.openoffice.org/3/user/uno_packages/cache/uno_packages/Kqal1c_/wiki-publisher.oxt/filter/odt2mediawiki.xsl:
line 44: Circular variable/parameter reference in '[param(CODE_TAB_REPLACEMENT),
param(CODE_STYLES), param(TABLE_CLASS), variable(USE_DEFAULT_TABLE_CLASS)]'.'
FATAL ERROR:  'Could not compile stylesheet'
com.sun.star.task.ErrorCodeIOException: 
    at com.sun.star.bridges.jni_uno.JNI_proxy.dispatch_call(Native Method)
    at com.sun.star.bridges.jni_uno.JNI_proxy.invoke(JNI_proxy.java:178)
    at $Proxy47.storeToURL(Unknown Source)
    at com.sun.star.wiki.WikiEditorImpl.SendArticleImpl(Unknown Source)
    at com.sun.star.wiki.WikiPropDialog$1.run(Unknown Source)

same issue as merriam, I suppose the connection may work better, since I do not
have the first bad issues.But I can not confirm at the moment, because of the
following issue :

 as I stated in my comment Nov 18 13:22:22, there is another issue with xslt
transform, the File->export to mediawiki does not work and produces the same
mistake...:

ERROR: 
'file:///home/steph/.openoffice.org/3/user/uno_packages/cache/uno_packages/O2fDqh_/wiki-publisher.oxt/filter/odt2mediawiki.xsl:
line 44: Circular variable/parameter reference in '[param(CODE_TAB_REPLACEMENT),
param(CODE_STYLES), param(TABLE_CLASS), variable(USE_DEFAULT_TABLE_CLASS)]'.'
FATAL ERROR:  'Could not compile stylesheet'

Do we need to open another issue ? for this problem or fill it in here....
Regards
steph

mav->merriam, sancelot:
The xslt transformation contains no circular reference. At least I see no.

The problem you mention looks to be a result of the bug in XALAN xslt parser
that is used in Ubuntu. The version 2.7.1 of XALAN has this bug, please see the
following link for details
http://mail-archives.apache.org/mod_mbox/xml-xalan-dev/200802.mbox/%3C7365434.1201876156390.JavaMail.jira@brutus%3E

The workaround for the bug is to define the temporary variables as global ones,
I will try to introduce it. I have opened a successor issue 99703 for this.

Created attachment 60534 [details]
modified xslt

with the attached xslt everything works.
Please check I did not break anything in the xslt !
Regards
S.Ancelot

Can be mark as duplicate of issue 99703

duplicate

*** This issue has been marked as a duplicate of 99703 ***

Closed

Sorry, I have to reopen the issue. It is no duplicate to issue 99703. cmc has
solved the problem related to GNU Java, the mentioned issue was just an
additional scenario that has affected some users.

Setting back to fixed.

cmc has verified the version with integrated patch, it can not be verified on
our side. Setting to verified myself.

integrated DEV300_m47

I have an issue with similar stacktraces running Windows while I try to run the **Sample Code** for converting a simple ODT to a PDF. I took the latest SDK released 8/21/2014 4.1.1. I've been struggling to find any information on how to solve this error and this thread has been the closest thing so far. 

Please help and ask for any additional information you may need!
Thank You

Here is the stack trace:

com.sun.star.task.ErrorCodeIOException:
at com.sun.star.lib.uno.environments.remote.Job.remoteUnoRequestRaisedException(Job.java:173)
	at com.sun.star.lib.uno.environments.remote.Job.execute(Job.java:139)
	at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:334)
	at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:303)
	at com.sun.star.lib.uno.environments.remote.JavaThreadPool.enter(JavaThreadPool.java:87)
	at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.sendRequest(java_remote_bridge.java:636)
	at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.request(ProxyFactory.java:146)
	at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.invoke(ProxyFactory.java:128)
	at com.sun.proxy.$Proxy5.storeToURL(Unknown Source)
	at com.example.DocumentConverter.traverse(DocumentConverter.java:129)
	at com.example.DocumentConverter.main(DocumentConverter.java:212)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at com.sun.star.lib.loader.Loader.main(Loader.java:134)

(In reply to Meyer from comment #39)
> I have an issue with similar stacktraces running Windows while I try to run
> the **Sample Code** for converting a simple ODT to a PDF. I took the latest
> SDK released 8/21/2014 4.1.1. I've been struggling to find any information
> on how to solve this error and this thread has been the closest thing so
> far. 
> 
> Please help and ask for any additional information you may need!
> Thank You

You can find support on the User Forum or the API Mailing list:
https://openoffice.apache.org/mailing-lists.html#api-mailing-list-public
https://forum.openoffice.org/