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]
