[Laszlo-dev] ?SOAPElement class implementation
keiji Ono
keiji_ono at net8.co.jp
Tue Dec 25 00:56:31 PST 2007
Hi Henry,
Sorry for late response, and thank you for your description about soap
overview.
I am also checking this issue with you. :)
Those are basic questions.
1. May the thing which worked on 3.3.3 think that even RingDing nighty
build works?
Are there any change such like protocol and/or version?
2.And which file has those strings, '__LZloaderReturnData data=',
'...loadmc' and
'...responseheaders=' in the debug message that has shown in debug window ?
I did not find them in lps java files.
---- debug window message------
<whatString
xmlns="http://localhost:8080/axis/SoapStringSimpleReturn.jws"><s></s></whatString>
__LZloaderReturnData data= «Object#0| {..., stubinfo: [object Object],
stub: [object Object]}»
... loadmc= «LoadObj#1| soap://soap (loading)»
...responseheaders= undefined
Best,
Keiji Ono
Henry Minsky wrote:
>In case I wasn't clear, what I was recommending was still using the
>apache AXIS library on the server side
>to proxy the SOAP request. The code that comes with AXIS implements
>"derserializing" back to XML, so you just would use that, send the XML
>back to the client, and parse it there. It would be some work to
>correctly convert that into native javascript data types, so
>essentially you'd have to implement the SOAP
>parsing in javascript, and that would probably be somewhat slow. But
>ultimately that is the way to go forward
>for Flash 9. I am not sure what flex does for SOAP support, whether
>they have any client side libraries
>to assist in the protocol or anything.
>
>
>
>On Dec 17, 2007 7:38 PM, Henry Minsky <henry.minsky at gmail.com> wrote:
>
>
>>I can tell you how the flow of data works, at a high level. I'm sorry that
>>I won't have time to fix this though. If you can look at it that would
>>be great.
>>
>>Unfortunately the SOAP code as it organized now is difficult to understand.
>>The reason for that is that I was in the middle of rewriting it when
>>some other higher priority
>>issues came up.
>>
>>The flow of control is that a SOAP XML request is constructed on the
>>client, and sent as a lzt=data
>>request with the special URL of "soap:..." to the LPS server. That is
>>dispatched to the apache
>>SOAP client library, the SOAP request is sent to the back end service,
>>and the response
>>is then compiled directly into low level SWF byte code and sent to the
>>client. The byte code that
>>is constructed is code which when executed recreates the arrays,
>>lists, objects, and other data types
>>that the SOAP response contains.
>>
>>
>>
>>That was how it used to work but, in order to support DHTML, I
>>duplicated a lot of the code paths which compiled
>>the SOAP response to SWF, and instead made it generate JSON
>>(javascript), so that
>>it could be sent back and parsed by the browser for DHTML apps.
>>
>>The next step I was going to do was to completely eliminate the old
>>dedicated data compiler for SWF, and
>>instead use the DHTML JSON code path that I just added, and use the
>>regular Laszlo javascript compiler
>>to compile that into SWF byte code, to be sent back to SWF
>>applications. I did not get to do that yet
>>however, so there are still to parallel code paths, one for compiling
>>SWF SOAP responses and one for DHTML.
>>
>>The flow of control, if I recall correctly is something like this;
>>
>>The SOAP data requests come to the server with the special query arg
>>lzt=data and the 'url' query arg is soap:PATH_TO_SOAP_SERVICE
>>
>>
>>These are handled by org.openlaszlo.servlets.responders.ResponderDATA
>>
>>ResponderCache
>>
>>which makes a table for the different types of data queries, the ones
>>we care about are
>>
>>"soap-swf", and "soap-json"
>>
>>These map to org.openlaszlo.data.json.SOAPDataSource and
>>org.openlaszlo.data.swf.SOAPDataSource.
>>
>>For SWF, the SOAPDataSource calls the apache axis client, and then
>>converts the response to SWF byte code, using the some of the old
>>DataCompiler that we used to use for XML data. (For XML data, we use
>>the Flash XML parser now, but in Flash 5, we compiled the XML data
>>into swf byte code dynamically when using the server data proxy).
>>
>>
>>The SOAPDataSouce.getData methods creates an instanceof
>>org.openlaszlo.remote.swf.soap.LZSOAPService, which is where all the
>>work is done to convert the AXIS response to SWF. The class
>>org.openlaszlo.remote.swf.soap.encoding.SOAPDataEncoder is an object
>>which actually encodes SOAP data as SWF bytecode.
>>
>>SOAPDataEncoder works with the AXIS serializer/deserializer model,
>>with a set of classes SWFArrayDeserializer, SWFObjectDeserializer,
>>SWFSimpleDeserializer, where SOAP requests are "deserialized" from
>>some AXIS SOAP internal representation into SWF byte code.
>>
>>I hope that gives you an overview of what is happening. It has gotten
>>really overly complex, because it
>>grew out of the data server framework, and now has the DHTML code path as well.
>>
>>I have thought it might be easier to just start over and simply proxy
>>the SOAP response as XML back to the app, and
>>parse the SOAP response as XML on the client, rather than using the
>>extremely overly
>>general Apache AXIS library to act as an intermediate relay. Then we
>>wouldn't be messing around at a low level with the AXIS APIs for
>>serialization/deserialization, which are really bad in my opinion, and
>>we also
>>wouldn't be messing with the SWF byte code compiler, which won't work
>>anyway with Flash 9.
>>
>>So I actually would recommend rearchitecting this as a separate
>>servlet service, independent of the LPS server maybe.
>>
>>Sorry for all the confusion!
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>On Dec 17, 2007 3:33 AM, keiji Ono <keiji_ono at net8.co.jp> wrote:
>>
>>
>>>Hi,
>>>I am thinking this is critical issue.
>>>Are you going to fix it in the next version release( 4.0.8 or 4.1 ) ?
>>>I also wrote a comment in Jira, 'I do not know where to start'.
>>>If you give me a hint, i can try it to fix.
>>>
>>>
>>>Regards,
>>>Keiji Ono
>>>
>>>keiji Ono wrote:
>>>
>>>
>>>
>>>>I have filed this issue in JIRA. LPP-5172.
>>>>
>>>>Henry Minsky wrote:
>>>>
>>>>
>>>>
>>>>>I'm trying to reproduce the bug now.
>>>>>
>>>>>
>>>>>
>>>>>On Nov 26, 2007 11:59 PM, keiji Ono <keiji_ono at net8.co.jp> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi Henry,
>>>>>>
>>>>>>I have informed you about SOAP issue.
>>>>>>I have also attached the test programs. They were very simple test
>>>>>>programs.
>>>>>>You could located the jws file at $TOMCAT_HOME/webapps/axis and the
>>>>>>soaptest3.lzx at
>>>>>>your $LPS_HOME. I tested it with SWF and also they were tested on
>>>>>>the same
>>>>>>tomcat( 5.0.30 ).
>>>>>>When i checked it with lps-3.3.3, it worked fine, but using the latest
>>>>>>nighty( rev 7378 ) did not worked.
>>>>>>The mean of the 'did not worked' was it did not shown the return
>>>>>>strings
>>>>>>in the result text field.
>>>>>>The return strings did not returned from the server side to the client.
>>>>>>You can find it at as following the
>>>>>>messages.
>>>>>>Also i am going to chase this issue in nighty source, but i know you
>>>>>>can
>>>>>>find it out faster than me. :������������������������������������������������������
>>>>>>Those are the message in the debug window.
>>>>>>
>>>>>>Case: lps-3.3.3
>>>>>><whatString
>>>>>>xmlns="http://localhost:8080/axis/SoapStringSimpleReturn.jws"><s></s></whatString>
>>>>>>
>>>>>><whatString
>>>>>>xmlns="http://localhost:8080/axis/SoapStringSimpleReturn.jws"><s>aa</s></whatString>
>>>>>>
>>>>>>
>>>>>>Case: Nighty ( rev 7378 )
>>>>>><whatString
>>>>>>xmlns="http://localhost:8080/axis/SoapStringSimpleReturn.jws"><s></s></whatString>
>>>>>>
>>>>>>__LZloaderReturnData data= {..., stubinfo: [object Object], stub:
>>>>>>[object
>>>>>>Object]}
>>>>>>... loadmc= ������������������LoadObj#1| soap://soap (loading)������������������
>>>>>>...responseheaders= undefined
>>>>>>{..., stubinfo: [object Object], stub: [object Object]}
>>>>>>__LZloaderReturnData data= <whatString
>>>>>>xmlns="http://localhost:8080/axis/SoapStringSimpleReturn.jws"><s></s></whatString>
>>>>>>
>>>>>>... loadmc= ������������������LoadObj#1| soap://soap (loading)������������������
>>>>>>...responseheaders= null
>>>>>>rpc.lzx _handler {status: ok, message: ok, data: <whatString
>>>>>>xmlns="http://localhost:8080/axis/SoapStringSimpleReturn.jws"><s></s></whatString>,
>>>>>>
>>>>>>opinfo: [object Object], seqnum: 1}
>>>>>><whatString
>>>>>>xmlns="http://localhost:8080/axis/SoapStringSimpleReturn.jws"><s></s></whatString>
>>>>>>
>>>>>>
>>>>>>
>>>>>>Regards,
>>>>>>
>>>>>>
>>>>>>Keiji Ono
>>>>>>
>>>>>>
>>>>>>keiji Ono wrote:
>>>>>>
>>>>>>Hi Henry,
>>>>>>
>>>>>>I am preparing a small piece of this issue.
>>>>>>Because the original test case was a bit special.
>>>>>>So i build it on Axis environment. I am going to make it in this week.
>>>>>>Please wait for a few days.
>>>>>>
>>>>>>Thanks
>>>>>>Keiji Ono
>>>>>>Keiji_ono at net8.co.jp
>>>>>>
>>>>>>Henry Minsky wrote:
>>>>>>
>>>>>>
>>>>>>I'll try and see if there was any change to the code paths between
>>>>>>4.0.3 and 4.0.5.
>>>>>>
>>>>>>Do have a small piece of test code that I can run to confirm that I am
>>>>>>reproducing the issue? If so, can you attach that to a bug report
>>>>>>and file
>>>>>>it in JIRA? Send me an email when you do that, and I will take a look.
>>>>>>
>>>>>>
>>>>>>On 11/5/07, keiji Ono <keiji_ono at net8.co.jp> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I found a problem of SOAP action between 3.3.3 and latest nighty build
>>>>>>(4.1.x).
>>>>>>With a same LZX application and using SOAP data I/F.
>>>>>>3.3.3 could send data to LPS, but the nighty could not.
>>>>>>ex.
>>>>>>send data 'burabura'
>>>>>>debugging 'lzpostbody' in SOAPDataSource.java
>>>>>>on 3.3.3: <some tag>[![CDATA[burabura]]</some tag>
>>>>>>on 4.1.x: <some tag/>
>>>>>>* in effect, those data were encoded.
>>>>>>
>>>>>>SOAPDataSource.java had not any changes between them.
>>>>>>Are there some changing data interface specifications?
>>>>>>I confirmed it was OK till 4.0.3, but 4.0.5 and later were NG.
>>>>>>
>>>>>>Regards,
>>>>>>Keiji Ono
>>>>>>
>>>>>>
>>>>>>Henry Minsky wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>On 10/30/07, keiji Ono <keiji_ono at net8.co.jp> wrote:
>>>>>>
>>>>>>
>>>>>>I have checked Apache-Axis library. And i knew where it was implemented
>>>>>>but at the same time
>>>>>>i did not understand about my issue whether it was a spec or bug.
>>>>>>Then i
>>>>>>will ask it for Axis forum.
>>>>>>Thank you for everything.
>>>>>>
>>>>>>BTW, i have been seeing OpenLaszlo source code by now, i would like to
>>>>>>confirm and gather up my *understanding* on processing SOAP data. If
>>>>>>this is incorrect, please correct me.
>>>>>>
>>>>>>Issue: procedure SOAP message data to provide to client
>>>>>>Example data: <data tag>burabura data</data tag>
>>>>>>Process:
>>>>>>1. read SOAP data ( like the example data )
>>>>>>2. disintegrate in tag and data
>>>>>>3. the data will be converted to Flash data format
>>>>>>4. reassemble the tag and the data
>>>>>>5. put it out it to client by HttpServletResponse
>>>>>>
>>>>>>But i did not find the point of *reassemble* clearly.
>>>>>>
>>>>>>Hello Keiji,
>>>>>>
>>>>>>I was probably the last person to touch the SOAP code, when I
>>>>>>added support for the DHTML runtime.
>>>>>>
>>>>>>In SWF, the SOAP data is converted to flash, using the old data
>>>>>>compiler
>>>>>>which used to be used for XML data, but is no longer used for that.
>>>>>>
>>>>>>In the DHTML version of the SOAP code, the data is converted to
>>>>>>JSON format. This might be easier to understand than the swf code
>>>>>>paths, if
>>>>>>you look at the
>>>>>>output that is sent to the client. It is a JSON string which is just a
>>>>>>combination of string, number, and arrays and objects.
>>>>>>
>>>>>>
>>>>>>It had been my intention to rewrite the SOAP server code for the SWF
>>>>>>runtime, so that
>>>>>>instead of using the old data compiler, it would instead just use
>>>>>>the JSON
>>>>>>format that we now use for DHTML, and compile the JSON string to swf
>>>>>>with
>>>>>>the regular "script compiler" that all the other Laszlo code goes
>>>>>>through.
>>>>>>This would simplify
>>>>>>the code substantially on the server, as it would eliminate the two
>>>>>>duplicate
>>>>>>code paths that exist now for SWF and DHTML. Unfortunately I have
>>>>>>not had
>>>>>>time to do that.
>>>>>>
>>>>>>Henry
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>Best,
>>>>>>Keiji Ono
>>>>>>
>>>>>>��������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������ï¿
½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½
>>>>>>wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>We use "apache-axis" for this server-side job, see i.e. at
>>>>>>
>>>>>>
>>>>>>
>>>>>>org.openlaszlo.remote.swf.soap.encoding.SOAPDataEncoder#buildHeaders(org.apache.axis.message.SOAPHeader
>>>>>>
>>>>>>).
>>>>>>
>>>>>>
>>>>>>
>>>>>>So I guess you need to check the "axis.jar" (JavaDoc:
>>>>>>
>>>>>>
>>>>>>
>>>>>>"http://ws.apache.org/axis/java/apiDocs/org/apache/axis/message/package-summary.html
>>>>>>
>>>>>>")
>>>>>>
>>>>>>
>>>>>>
>>>>>>to get any further.
>>>>>>
>>>>>>-
>>>>>>Andr�������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������ï
¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>Hi Ben,
>>>>>>
>>>>>>Thank you for your reply.
>>>>>>Yes, i also found your point and i was searching the implementation.
>>>>>>If it did not implement in OpenLaszlo source, it must came from
>>>>>>saaj.jar or other jars.
>>>>>>As far as i know, this class declared as Interface class in SAAJ, so
>>>>>>i wondered
>>>>>>where did it implement.
>>>>>>In your opinion, OpenLaszlo depend on the standard of JARs, right?
>>>>>>If so, i would appreciate it if you gave me the information about
>>>>>>JARs version and so on.
>>>>>>
>>>>>>Best,
>>>>>>Keiji Ono
>>>>>>
>>>>>>Benjamin Shine wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>/
>>>>>>
>>>>>>/>/ It looks to me like SOAPElement is imported from />/
>>>>>>javax.xml.soap.SOAPElement:
>>>>>>/>/
>>>>>>/>/ $ grep SOAPElement `find . -name "SOAP*.java"`
>>>>>>/>/ ...
>>>>>>/>/
>>>>>>
>>>>>>./WEB-INF/lps/server/src/org/openlaszlo/remote/swf/soap/encoding/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>/>/ SOAPDataEncoder.java :
>>>>>>/>/ import javax.xml.soap.SOAPElement;
>>>>>>/>/ ...
>>>>>>/>/
>>>>>>/>/ So that implementation must come from one of the jars we ship
>>>>>>with, />/ but I don't know which one.
>>>>>>/>/
>>>>>>/>/ Is this the information you were looking for?
>>>>>>/>/ -ben
>>>>>>/>/
>>>>>>/>/
>>>>>>/>/ On Oct 25, 2007, at 6:13 PM, keiji Ono wrote:
>>>>>>/>/
>>>>>>/>>/ Hi
>>>>>>/>>/
>>>>>>/>>/ I could make in focus on this issue.
>>>>>>/>>/ I found the method of .getChildElements() was rejecting all blanks
>>>>>>/>>/ at the head and tail of SOAPElement class.
>>>>>>/>>/ But as you know, SOAPElement class was declared by Interface
>>>>>>class in />>/ SAAJ.
>>>>>>/>>/ As the next step, i checked how SOAPElement class had
>>>>>>implemented in />>/ OpenLaszlo.
>>>>>>/>>/ but i could not find the point in OpenLaszlo source.
>>>>>>/>>/ If i could find it, i could know it whether it was bug or spec.
>>>>>>/>>/ Hey Server Side Men, could you give some hints for me?
>>>>>>/>>/
>>>>>>/>>/ Best,
>>>>>>/>>/ Keiji Ono
>>>>>>/>>/
>>>>>>/>>/ keiji Ono wrote:
>>>>>>/>>/
>>>>>>/>>>/ I have been continuing to solve this issue.
>>>>>>/>>>/ And i look at the point of the suspicious, but i could not know
>>>>>>it />>>/ clearly.
>>>>>>/>>>/ At the point is in SOAPDataEncoder.java.
>>>>>>/>>>/ The 'issue' code is in the method of _traverseDOM().
>>>>>>/>>>/
>>>>>>/>>>/ SOAPDataEncoder.java _traverseDOM()
>>>>>>/>>>/
>>>>>>/>>>/ iter = el.getChildElements();
>>>>>>/>>>/ while(iter.hasNext()){
>>>>>>/>>>/ Object o = iter.next(); <---- 1
>>>>>>/>>>/ if( Text.class.isInstance(o) ){
>>>>>>/>>>/ characters(((Text)o).getValue() ); <---- 2
>>>>>>/>>>/ }else{
>>>>>>/>>>/ .
>>>>>>/>>>/ .
>>>>>>/>>>/ }
>>>>>>/>>>/ }
>>>>>>/>>>/
>>>>>>/>>>/ At the point of 1, when the Object o contained a string
>>>>>>/>>>/ "<sometag><![CDATA[ Text Strings]]></sometag>",
>>>>>>/>>>/ .getValue() at the point of 2 got the string "Text Strings" and
>>>>>>/>>>/ set it to the method of characters(). The characters()
>>>>>>/>>>/ push it to client through FlashBuffer class.
>>>>>>/>>>/ The issue of it is the blank of the start strings has been
>>>>>>rejected />>>/ by getValue().
>>>>>>/>>>/
>>>>>>/>>>/ I do not know whether this is the specification of getValue()
>>>>>>of />>>/ org.apache.xml.message.Text class.
>>>>>>/>>>/ Is not there the person knowing a lot about this?
>>>>>>/>>>/
>>>>>>/>>>/ Keiji Ono
>>>>>>/>>>/
>>>>>>/>>>>/ Hummm, it did not effect to the log file.
>>>>>>/>>>>/ Basically, i did not use multibyte data, so whichever use
>>>>>>UTF-8 />>>>/ parameter in the properties file,
>>>>>>/>>>>/ it did not effect to it, i think.
>>>>>>/>>>>/
>>>>>>/>>>>/ BTW, the reason why i am taking this issue, because i have a
>>>>>>/>>>>/ trouble on SOAP data handling on LPS.
>>>>>>/>>>>/ The trouble is like this.
>>>>>>/>>>>/ When i sent data from a OpenLaszlo application, like ' ABC' to
>>>>>>SOAP />>>>/ server, but the return was
>>>>>>/>>>>/ 'ABC'. Pay attention this, LPS cut out those spaces of the data.
>>>>>>/>>>>/ I traced how to treat the data in LPS, so i reached
>>>>>>FileUtil.java. />>>>/ I know the data from SOAP server
>>>>>>/>>>>/ to LPS are correct, that mean the data has the spaces.
>>>>>>/>>>>/
>>>>>>/>>>>/ Any advances. Thank you.
>>>>>>/>>>>/
>>>>>>/>>>>/ Keiji Ono
>>>>>>/>>>>/
>>>>>>/>>>>/
>>>>>>/>>>>/ P T Withington wrote:
>>>>>>/>>>>/
>>>>>>/>>>>>/ I wonder if the problem is that log4j is not configured for
>>>>>>UTF8? />>>>>/ I found this with Google:
>>>>>>/>>>>>/
>>>>>>/>>>>>>/ Debugging can be fun with high byte characters as generally
>>>>>>/>>>>>>/ logging to a console isn't going to show you the characters
>>>>>>you />>>>>>/ are expecting. If you did this:
>>>>>>/>>>>>>/
>>>>>>/>>>>>>/ System.out.println(new String(new byte[] { -28, -72,
>>>>>>-83},"UTF-8")
>>>>>>/>>>>>>/
>>>>>>/>>>>>>/ Then you'd probably just see a ? rather than the Chinese
>>>>>>/>>>>>>/ character that it really should be. However, you can make
>>>>>>log4j />>>>>>/ log UTF-8 messages. Just add
>>>>>>/>>>>>>/
>>>>>>/>>>>>>/ <param name="Encoding" value="UTF-8"/>
>>>>>>/>>>>>>/
>>>>>>/>>>>>>/ To the appender in your log4j.xml config. Or this:
>>>>>>/>>>>>>/
>>>>>>/>>>>>>/ log4j.appender.myappender.Encoding=UTF-8
>>>>>>/>>>>>>/
>>>>>>/>>>>>>/ To your log4j.properties file. You might still only see the
>>>>>>UTF-8 />>>>>>/ data properly if you view the log file in an editor/
>>>>>>viewer that />>>>>>/ can view UTF-8 data (Windows notepad is ok for
>>>>>>instance).
>>>>>>/>>>>>/
>>>>>>/>>>>>/
>>>>>>/>>>>>/
>>>>>>/>>>>>/
>>>>>>/>>>>>/
>>>>>>/>>>>>/ [Java UTF???????????????????????????8 international character
>>>>>>/>>>>>/ support with Tomcat and Oracle, 26/03/07, Kieran's
>>>>>>blog](http:// />>>>>/
>>>>>>
>>>>>>blogs.warwick.ac.uk/kieranshaw/entry/ />>>>>/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>utf-8_internationalisation_with/)
>>>>>>/>>>>>/
>>>>>>/>>>>>/ Also, I wonder if using the Firebug extension to Firefox
>>>>>>might />>>>>/ help. Using the Net pane, you should be able to see the
>>>>>>content of />>>>>/ the http get.
>>>>>>/>>>>>/
>>>>>>/>>>>>/ On 2007-09-27, at 20:20 EDT, keiji Ono wrote:
>>>>>>/>>>>>/
>>>>>>/>>>>>>/ Who dose maintenance this Java file ?
>>>>>>/>>>>>>/ If you give me a little tip, i can progress on it.
>>>>>>/>>>>>>/
>>>>>>/>>>>>>/ keiji Ono wrote:
>>>>>>/>>>>>>/
>>>>>>/>>>>>>>/ Ben,
>>>>>>/>>>>>>>/
>>>>>>/>>>>>>>/ Thank you for your suggestion, but i tried already it on
>>>>>>4.0.5 />>>>>>>/ as a trial ,
>>>>>>/>>>>>>>/ but it did not work on it.
>>>>>>/>>>>>>>/ I know it worked till on 4.0.3. :@
>>>>>>/>>>>>>>/
>>>>>>/>>>>>>>/ It will be good if i can give you a sample code of it , but
>>>>>>as />>>>>>>/ you know
>>>>>>/>>>>>>>/ it is not
>>>>>>/>>>>>>>/ easy to give SOAP sample.
>>>>>>/>>>>>>>/ And our application is now working on 3.3.3, so i would
>>>>>>like to />>>>>>>/ try on
>>>>>>/>>>>>>>/ 3.3.3.
>>>>>>/>>>>>>>/
>>>>>>/>>>>>>>/ I am thinking as following steps now.
>>>>>>/>>>>>>>/ 1. Check it on 3.3.3
>>>>>>/>>>>>>>/ 2. If i find looks like bug in it, i will change it.
>>>>>>/>>>>>>>/ 3. Then i am going to look at 4.0.5 source.
>>>>>>/>>>>>>>/
>>>>>>/>>>>>>>/ So could you give some advance?
>>>>>>/>>>>>>>/ Thank you.
>>>>>>/>>>>>>>/
>>>>>>/>>>>>>>/ Keiji ono
>>>>>>/>>>>>>>/
>>>>>>/>>>>>>>/ Benjamin Shine wrote:
>>>>>>/>>>>>>>/
>>>>>>/>>>>>>>/
>>>>>>/>>>>>>>/
>>>>>>/>>>>>>>>/ Keiji, I suggest you work with lps-4.0.5. It is the most
>>>>>>/>>>>>>>>/ current, and
>>>>>>/>>>>>>>>/ we are more likely to be familiar with the code that
>>>>>>you're />>>>>>>>/ working
>>>>>>/>>>>>>>>/ with. See
>>>>>>/>>>>>>>>/ http://www.openlaszlo.org/node/383
>>>>>>/>>>>>>>>/ for the announcment.
>>>>>>/>>>>>>>>/
>>>>>>/>>>>>>>>/ -ben
>>>>>>/>>>>>>>>/
>>>>>>/>>>>>>>>/ On Sep 26, 2007, at 5:03 AM, keiji Ono wrote:
>>>>>>/>>>>>>>>/
>>>>>>/>>>>>>>>/
>>>>>>/>>>>>>>>/
>>>>>>/>>>>>>>>>/ Adding, it was the source of lps-3.3.3, and the data was
>>>>>>not />>>>>>>>>/ multibyte
>>>>>>/>>>>>>>>>/ character.
>>>>>>/>>>>>>>>>/
>>>>>>/>>>>>>>>>/ Keiji Ono
>>>>>>/>>>>>>>>>/
>>>>>>/>>>>>>>>>/
>>>>>>/>>>>>>>>>/
>>>>>>/>>>>>>>>>>/ Hi all,
>>>>>>/>>>>>>>>>>/
>>>>>>/>>>>>>>>>>/ I am checking about Input/Output data on LPS now.
>>>>>>/>>>>>>>>>>/ Because when i take SOAP interface on my application,
>>>>>>the />>>>>>>>>>/ getting data
>>>>>>/>>>>>>>>>>/ is wrong.
>>>>>>/>>>>>>>>>>/ Then i would like to check data where output from LPS.
>>>>>>/>>>>>>>>>>/ At the point of FileUtils.java, i add some code like
>>>>>>following
>>>>>>/>>>>>>>>>>/ (BlockName-A).
>>>>>>/>>>>>>>>>>/ But it got unreadable data to write lps.log as following.
>>>>>>/>>>>>>>>>>/ How can i get 'readable' log on lps.log ?
>>>>>>/>>>>>>>>>>/
>>>>>>/>>>>>>>>>>/ <checking code on FileUtils.java>
>>>>>>/>>>>>>>>>>/ public static int sendToStream(InputStream input,
>>>>>>/>>>>>>>>>>/ OutputStream output, int size)
>>>>>>/>>>>>>>>>>/ throws IOException {
>>>>>>/>>>>>>>>>>/ int c = 0;
>>>>>>/>>>>>>>>>>/ byte[] buffer = new byte[size];
>>>>>>/>>>>>>>>>>/ int b = 0;
>>>>>>/>>>>>>>>>>/ while(true) {
>>>>>>/>>>>>>>>>>/ try {
>>>>>>/>>>>>>>>>>/ // Until end of stream
>>>>>>/>>>>>>>>>>/ if ((b = input.read(buffer)) <= 0) {
>>>>>>/>>>>>>>>>>/ return c;
>>>>>>/>>>>>>>>>>/ }
>>>>>>/>>>>>>>>>>/ } catch (IOException e) {
>>>>>>/>>>>>>>>>>/ throw new StreamReadingException( e.getMessage());
>>>>>>/>>>>>>>>>>/ }
>>>>>>/>>>>>>>>>>/ c += b;
>>>>>>/>>>>>>>>>>/ try {
>>>>>>/>>>>>>>>>>/ output.write(buffer, 0, b);
>>>>>>/>>>>>>>>>>/
>>>>>>/>>>>>>>>>>/ //=== adding from here BlockName-A
>>>>>>/>>>>>>>>>>/ {
>>>>>>/>>>>>>>>>>/ String aString = new String(buffer, "UTF-8");
>>>>>>/>>>>>>>>>>/ mLogger.debug( "OUTPUT: " + aString );
>>>>>>/>>>>>>>>>>/ }
>>>>>>/>>>>>>>>>>/ //=== to here
>>>>>>/>>>>>>>>>>/
>>>>>>/>>>>>>>>>>/ <lps.log>
>>>>>>/>>>>>>>>>>/ OUTPUT: FWS 4 x F ? `
>>>>>>/>>>>>>>>>>/ xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx? ? ?0
>>>>>>
>>>>>>_m _t CSPCHD id
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>/>>>>>>>>>>/ AddLongResponse AddLongResult ? _m _root /? _m N
>>>>>>? _t >>>>>>>>>>/ _root /?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>/ _t N
>>>>>>
>>>>>>/? ? _root ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>/ _rootndi RL? C? =L? C? =L?;
>>>>>>
>>>>>>/>>>>>>>>>>/
>>>>>>0000000100001gUD5zy4000000XKonfBejSj6FIgaG0jaWHQ--
>>>>>>
>>>>>>= ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>/>>>>>>>>>>/ ?
>>>>>>/>>>>>>>>>>/ _root /? _finishndi R? B? ? _root ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>/ _rootndi RL? C? =L? C? =L?
>>>>>>
>>>>>>/>>>>>>>>>>/ GHGHGH = ? ? _root /? _finishndi R? B?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>/ _parent /? ?
>>>>>>/ _parent /? loader N? returnData R @
>>>>>>/
>>>>>>
>>>>>>/>>>>>>>>>>/ Thanks any advance.
>>>>>>/>>>>>>>>>>/
>>>>>>/>>>>>>>>>>/ Keiji Ono
>>>>>>/>>>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>--
>>>>>>Henry Minsky
>>>>>>Software Architect
>>>>>>hminsky at laszlosystems.com
>>>>>>
>>>>>>
>>>>>>public class SoapStringSimpleReturn {
>>>>>>private String returnString = new String();
>>>>>>/*
>>>>>>public String getReturnString() {
>>>>>>return returnString;
>>>>>>}
>>>>>>
>>>>>>public void setReturnString(String returnString) {
>>>>>>this.returnString = returnString;
>>>>>>}
>>>>>>*/
>>>>>>public String whatString( String s ){
>>>>>>return s;
>>>>>>}
>>>>>>}
>>>>>>
>>>>>>
>>
>>--
>>Henry Minsky
>>Software Architect
>>hminsky at laszlosystems.com
>>
>>
>>
More information about the Laszlo-dev
mailing list