Amy Muntz - 22/Sep/05 10:02 AM Here is a workaround that makes their test case work: write the method like this to convert the string arg to UTF8    public String echo2(String val, Vector vec) {        String ustr = ( String )vec.elementAt(0);        byte p[];        try {            //p = v[i].getBytes("UTF-8"); // WORKS for PROXIED POST            p = ustr.getBytes("ISO-8859-1"); // OK for GET, proxied and direct            String rstr = new String(p, 0, p.length, "UTF-8");            return "val="+val + " :: "+val.length()+" vec[0]="+rstr+" :: "+ rstr.length();        } catch (Exception e) {            return "caught exception "+e;        }    } The question is where to put this string mashing code on the server before the rpc method gets invoked, to make sure the arguments are encoded properly. ================  Pablo Kang to me, Oliver Sep 21 (21 hours ago) The code that parses the XML-RPC args is in org.openlaszlo.remote.LzXMLRPCRequestProcessor which basically extends org.apache.xmlrpc.XMLRPCRequestProcessor. XMLRPCRequestProcessor has an API to parse methods and parameters from the input stream. JavaRPC always uses POST because it uses XML-RPC to communicate between client and server. ================================================================  Henry Minsky to Pablo, Oliver Sep 21 (20 hours ago) http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/XmlRpcRequestProcessor.html#decodeRequest(java.io.InputStream) I tried looking at these docs and then compiling something like this public class LZXmlRpcRequestProcessor extends XmlRpcRequestProcessor {    public LZXmlRpcRequestProcessor() {        super();    }    public XmlRpcServerRequest decodeRequest(java.io.InputStream is) {        this.setInputEncoding("ISO-8859-1");        return super.decodeRequest(is);    } } But I get compiler errors - what version of the apache xmlrpc library are we using? compile:    [javac] Compiling 7 source files to C:\sandboxes\lps-dev\WEB-INF\lps\server\build ================================================================  Pablo Kang to me, Oliver Sep 21 (19 hours ago) Can you try it with XML-RPC 2.0? It compiled for me, but I haven't had a chance to test it. Attached is the jar file. On Wed, 21 Sep 2005, Henry Minsky wrote: >> Well, I don't know why I can't compile my own decodeRequest method, >> maybe you can take a whack at it. I thought maybe if i could call that >> setInputEncoding() method, it would make everything work magically. >> >> On 9/21/05, Pablo Kang <pkang@laszlosystems.com> wrote: >>>> I believe it's 1.2b1. We're using xmlrpc-1.2-b1.jar. >>>> >>>> pablo >>>> >>>> >>>> On Wed, 21 Sep 2005, Henry Minsky wrote: http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/XmlRpcRequestProcessor.html#decodeRequest(java.io.InputStream) >>>>>> >>>>>> I tried looking at these docs and then compiling something like this >>>>>> >>>>>> public class LZXmlRpcRequestProcessor extends XmlRpcRequestProcessor >>>>>> { >>>>>> public LZXmlRpcRequestProcessor() { >>>>>> super(); >>>>>> } >>>>>> >>>>>> public XmlRpcServerRequest decodeRequest(java.io.InputStream is) { >>>>>> this.setInputEncoding("ISO-8859-1"); >>>>>> return super.decodeRequest(is); >>>>>> } >>>>>> >>>>>> >>>>>> } >>>>>> >>>>>> >>>>>> But I get compiler errors - what version of the apache xmlrpc library >>>>>> are we using? >>>>>> >>>>>> >>>>>> compile: >>>>>> [javac] Compiling 7 source files to >>>>>> C:\sandboxes\lps-dev\WEB-INF\lps\server\build >>>>>> >>>>>> [javac] Found 3 semantic errors compiling >>>>>> "C:/sandboxes/lps-dev/WEB-INF/lps/server/src/org/openlaszlo/remote/LZXmlRpcRequestProcessor.java": >>>>>> >>>>>> [javac] 20. public org.apache.xmlrpc.XmlRpcServerRequest >>>>>> decodeRequest(java.io.InputStream is) { >>>>>> [javac] ^-----------------^ >>>>>> [javac] *** Semantic Error: Type >>>>>> org.apache.xmlrpc.XmlRpcServerRequest was not found. >>>>>> >>>>>> >>>>>> [javac] 21. this.setInputEncoding("ISO-8859-1"); >>>>>> [javac] ^---------------------------------^ >>>>>> [javac] *** Semantic Error: No method named "setInputEncoding" was >>>>>> found in type "org.openlaszlo.remote.LZXmlRpcRequestProcessor". >>>>>> >>>>>> >>>>>> [javac] 22. return super.decodeRequest(is); >>>>>> [javac] ^---------------------^ >>>>>> [javac] *** Semantic Error: No method named "decodeRequest" was >>>>>> found in type "org.apache.xmlrpc.XmlRpcRequestProcessor". >>>>>> >>>>>> BUILD FAILED >>>>>> file:C:/sandboxes/lps-dev/WEB-INF/lps/server/build.xml:315: Compile >>>>>> failed; see the compiler error output for details. >>>>>> >>>>>> Total time: 2 seconds >>>>>> >>>>>> hqm@domokun /cygdrive/c/sandboxes/lps-dev >>>>>> >>>>>> On 9/21/05, Pablo Kang <pkang@laszlosystems.com> wrote: >>> >>>>>>>> The code that parses the XML-RPC args is in >>>>>>>> org.openlaszlo.remote.LzXMLRPCRequestProcessor which basically extends >>>>>>>> org.apache.xmlrpc.XMLRPCRequestProcessor. XMLRPCRequestProcessor has an >>>>>>>> API to parse methods and parameters from the input stream. >>>>>>>> >>>>>>>> JavaRPC always uses POST because it uses XML-RPC to communicate between >>>>>>>> client and server. >>>>>>>> >>>>>>>> pablo >>>>>>>> >>>>>>>> On Wed, 21 Sep 2005, Henry Minsky wrote: >>>>>>>> >>>> >>>>>>>>>> Where is the code on the server that grabs the XMLRPC args from the >>>>>>>>>> client when a request comes in? It needs to find and convert the >>>>>>>>>> incoming string encoding somehow. >>>>>>>>>> Does JavaRPC always use POST method? >>>>>>>>>> >>>>>>>>>> On 9/21/05, Henry Minsky <henry.minsky@gmail.com> wrote: >>>>> >>>>>>>>>>>> Here is a workaround that makes their test case work: >>>>>>>>>>>> >>>>>>>>>>>> write the method like this to convert the string arg to UTF8 >>>>>>>>>>>> >>>>>>>>>>>> public String echo2(String val, Vector vec) { >>>>>>>>>>>> String ustr = ( String )vec.elementAt(0); >>>>>>>>>>>> byte p[]; >>>>>>>>>>>> try { >>>>>>>>>>>> //p = v[i].getBytes("UTF-8"); // WORKS for PROXIED POST >>>>>>>>>>>> p = ustr.getBytes("ISO-8859-1"); // OK for GET, proxied and direct >>>>>>>>>>>> String rstr = new String(p, 0, p.length, "UTF-8"); >>>>>>>>>>>> >>>>>>>>>>>> return "val="+val + " :: "+val.length()+" vec[0]="+rstr+" >>>>>>>>>>>> :: "+ rstr.length(); >>>>>>>>>>>> } catch (Exception e) { >>>>>>>>>>>> return "caught exception "+e; >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> The question is where to put this string mashing code on the server >>>>>>>>>>>> before the rpc method gets invoked, to make sure the arguments are >>>>>>>>>>>> encoded properly. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 9/21/05, Henry Minsky wrote: >>>>>> >>>>>>>>>>>>>> I wrote an Echo.java class like this >>>>>>>>>>>>>> >>>>>>>>>>>>>> /****************************************************************************** >>>>>>>>>>>>>> * Echo.java >>>>>>>>>>>>>> * ****************************************************************************/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> /* J_LZ_COPYRIGHT_BEGIN ******************************************************* >>>>>>>>>>>>>> * Copyright 2001-2004 Laszlo Systems, Inc. All Rights Reserved. * >>>>>>>>>>>>>> * Use is subject to license terms.                * >>>>>>>>>>>>>> * J_LZ_COPYRIGHT_END *********************************************************/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> package org.openlaszlo.test.xmlrpc; >>>>>>>>>>>>>> >>>>>>>>>>>>>> import java.util.*; >>>>>>>>>>>>>> >>>>>>>>>>>>>> public class Echo >>>>>>>>>>>>>> { >>>>>>>>>>>>>> public Echo() { >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> public String echo(String val) { >>>>>>>>>>>>>> return val + " :: "+val.length(); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> public String echo2(String val, Vector vec) { >>>>>>>>>>>>>> return "val="+val + " :: "+val.length()+" >>>>>>>>>>>>>> vec[0]="+vec.elementAt(0)+" :: "+ ((String) >>>>>>>>>>>>>> vec.elementAt(0)).length(); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> And modified their test case, and indeed it shows corrupted Unicode >>>>>>>>>>>>>> chars coming back, in the latest lps-dev >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 9/21/05, Henry Minsky wrote: >>>>>>> >>>>>>>>>>>>>>>> It calls out to some class >>>>>>>>>>>>>>>> <javarpc classname="es.caib.seycon.net.lzx.EJBInvoker" name="ejb" >>>>>>>>>>>>>>>> scope="session" objectreturntype="javabean" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> which I don't think we have, and I don't know how to install anyway. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Maybe Pablo would have an idea. Perhaps we have a simple "echo" RPC >>>>>>>>>>>>>>>> test class we could use to just test the round trip character >>>>>>>>>>>>>>>> handling? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 9/21/05, Oliver Steele <osteele@laszlosystems.com> wrote: >>>>>>>> >>>>>>>>>>>>>>>>>> Henry, could you look at the enclosed file? Does this fail for you in the >>>>>>>>>>>>>>>>>> latest build? >>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi Nicholas. > >We are thinking about buying the support but we found some >>>>>>>>>>>>>>>>>> problems that >keep my boss in doubt. > >We have a problem with the encoding >>>>>>>>>>>>>>>>>> of the data send to a Database, when we >send the data using JAVARPC the >>>>>>>>>>>>>>>>>> data arrives to the JavaBean with no >accents and strange characters >>>>>>>>>>>>>>>>>> example: ó instead of ó ,That is a big >problem that keep my boss wondering >>>>>>>>>>>>>>>>>> is Laszlo is the right decision and a >good product to spend our money. > >>>>>>>>>>>>>>>>>>>> Any help will be appreciate. > >Regards > >Valentín Ginard. > > > > > >>>>>>>>> >>>>>>>>>>>>>>>>>> Nicholas Buck > ems.com> Para > vginard@dgtic.caib.es > 10/09/2005 08:51 cc >>>>>>>>>>>>>>>>>>>>>> Asunto > Laszlo Support Standard and Premium > > > > > > > > > > >>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Greetings, > >Valentin - did you receive my response from the 7th? > >What >>>>>>>>>>>>>>>>>> are your thoughts? > >Regards, > >Nick > > > >Nicholas Buck ? Strategic >>>>>>>>>>>>>>>>>> Account Director ? direct 650 338 2715 ? cell >408 390-8239 ? fax 650 338 >>>>>>>>>>>>>>>>>> 2790 ? nbuck@laszlosystems.com > > > (Embedded image moved to file: >>>>>>>>>>>>>>>>>> pic05436.jpg) > > >(See attached file: nbuck.vcf) > > > > > >>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------ xmlrpc-2.0.jar 95K Download Henry Minsky to Pablo, Oliver Sep 21 (19 hours ago) It compiles for me, but when I run the app I get this ---------- onerror: «string(3102)#0| "org/apache/commons/codec/DecoderException : Exception stack: java.lang.NoClassDefFoundError: org/apache/commons/codec/DecoderException at org.apache.xmlrpc.XmlRpc.createTypeFactory(XmlRpc.java:238) at org.apache.xmlrpc.XmlRpc.<init>(XmlRpc.java:193) at org.apache.xmlrpc.XmlRpcRequestProcessor.<init>(XmlRpcRequestProcessor.java:40)  at org.openlaszlo.remote.LZXmlRpcRequestProcessor.<init>(LZXmlRpcRequestProcessor.java:17)  at org.openlaszlo.data.JavaDataSource.getData(JavaDataSource.java:223)  at org.openlaszlo.data.DataSource.getAsSWF(DataSource.java:98) at org.openlaszlo.servlets.responders.ResponderCache.respondImpl(ResponderCache.java:373)  at org.openlaszlo.servlets.responders.Responder.respond(Responder.java:217)  at org.openlaszlo.servlets.LZServlet._doGet(LZServlet.java:302) at org.openlaszlo.servlets.LZServlet.doGet(LZServlet.java:238) at org.openlaszlo.servlets.LZServlet.doPost(LZServlet.java:370) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at java...» WARNING: echorpc.lzx:9: reference to undefined property 'error_a

Pablo Kang - 28/Sep/05 03:26 AM I'm still trying to figure out how the server ends up getting data as ISO-8859-1 instead of UTF-8. Does Flash always post data in UTF-8? If so, the server is somehow getting its data as ISO-8859-1 and we need to transcode that back to UTF-8 before we push that data back to the client.

Henry Minsky - 28/Sep/05 04:57 AM One theory is that the Flash client POSTs the data as UTF-8, but doesn't use a HTTP header that declares that, so the apache server assumes ISO-8859-1 as a default. Someone on the mailing list suggested that if we could get Flash to add a HTTP content type with a charset declaring UTF-8 it might work, but there's no way to do that that I know of.

Pablo Kang - 02/Oct/05 07:24 PM Ok, it looks like by default Tomcat decodes strings into ISO-8859-1. From http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/http.html:   URIEncoding:   This [attribute] specifies the character encoding used to   decode the URI bytes, after %xx decoding the URL. If not   specified, ISO-8859-1 will be used. I tried setting this attribute to UTF-8 with server.xml with no luck. The only luck I've had so far with getting international characters (latin, japanese, korean) to work is by setting tomcat to startup with a "-Dfile.encoding=UTF-8" property and by explicitly converting the postbody from ISO-8859-1 to UTF-8 like Henry did in one of his test cases:         // Not clear why postbody is encoded as an ISO-8859-1 string.         try {             byte p[] = postbody.getBytes("ISO-8859-1");             postbody = new String(p, 0, p.length, "UTF-8");         } catch (UnsupportedEncodingException e){         }

Pablo Kang - 02/Oct/05 10:04 PM Test case checked into //depot/lps-dev/test/bugs/lpp-716.lzx (change 33251).

Pablo Kang - 03/Oct/05 04:00 PM Fixed in lps-dev (change 33296).

Mark Davis - 14/Oct/05 11:53 AM Provided testcase properly displays the characters. Verified