That is the way to go in my opinion.
On Dec 18, 2007 3:41 PM, Elliot Winard <[EMAIL PROTECTED]> wrote: > I'm not sure about the latest build of Flex, but Flex 1.0 and Flex 1.5 > handled SOAP using client-side libraries. > -e > > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > >>>>>> [EMAIL PROTECTED] > >>>>>> > >>>>>> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > >>>>>> [EMAIL PROTECTED] > >>>>>> > >>>>>> > >>>>>> 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 > >> [EMAIL PROTECTED] > >> > >> > > > > > > > > > -- Henry Minsky Software Architect [EMAIL PROTECTED]
