[Laszlo-dev] ?SOAPElement class implementation

keiji Ono keiji_ono at net8.co.jp
Mon Dec 17 00:33:39 PST 2007


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;
>>> }
>>> }
>>


More information about the Laszlo-dev mailing list