Andreas,

Thank you very much for researching this. Great job finding the underlying 
cause and proposing a fix. I'll watch the JIRA and get the build with the fix 
when it is available.

Scott

----- Original Message ----
From: Andreas Veithen <[EMAIL PROTECTED]>
To: [email protected]
Sent: Monday, January 14, 2008 4:49:12 PM
Subject: Re: Process SOAP message containg XHTML


Dear all,

I was able to reproduce Scott's problem and I identified  
OMElementImpl#getText as the culprit: this method uses a particular  
inefficient way to do string concatenations. By using a StringBuffer  
(as you learn in any introductory course on Java...) I was able to  
reduce processing time from about 30s to 0.1s. I will open a JIRA  
issue (if there is none yet) and submit a patch.

Regards,

Andreas

On 14 Jan 2008, at 21:14, Scott Malinowski wrote:

> Philipp,
>
> I tried the CDATA already and it didn't work. Axis2 just encoded it  
> right along with the XHTML.
>
> I agree with your comments about the gracefulness (or rather  
> gracelessness) of sending XHTML as a string in a SOAP message. I  
> need a cross-platform way of returning XHTML documents and a web  
> service seemed like the best approach. Mainly because of how the web
  
> service is called. The web service needs to receive complex data  
> types, which are easily built when constructed via nested elements  
> in XML. Therefore, in my limited knowledge of web technologies, web  
> services seemed best and we are already calling a web service in a  
> different organization using SOAP so that is where I have been  
> concentrating my efforts. I am, however, always open to better ideas
  
> and solutions. I am unaware of RESTful web services but will check  
> it out.
>
> Thanks a lot!
>
> Scott
>
> ----- Original Message ----
> From: Philipp Leitner <[EMAIL PROTECTED]>
> To: [email protected]
> Sent: Monday, January 14, 2008 2:00:33 PM
> Subject: Re: Process SOAP message containg XHTML
>
> Probably including XHTML document in a CDATA section helps, i.e.  
> instead
> of passing back
>
> <html>
> ..
> </html>
>
> you pass back
>
> <![CDATA[
> <html>
> ..
> </html>
> ]]>
>
> (on client-side you would obviously have to strip the CDATA tags  
> again).
>
> On a sidenote, I am not sure if your design (Web service that  
> returns a
> XHTML response encoded as String) is so beautiful. Have you ever  
> though
> about writing a RESTful Web service without SOAP, that just returns  
> XML
> or XHTML representations? Would seem like a simpler and more
> understandable solution to your challenges...
>
> /philipp
>
> Scott Malinowski schrieb:
> > Paul,
> >
> > Thanks. I saw MTOM during my research but I am very new to web  
> services
> > and SOAP and I am finding some of these other features (including  
> MTOM)
> > a bit daunting. Mostly, I need to make sure the web service I  
> write can
> > be accessed not only by my Java client but also by our sister
> > application, which is written in PowerBuilder. It looks like you  
> have to
> > enable MTOM on the client but I am unable to find how that can be  
> done
> > in PowerBuilder. It appears you have to have PowerBuilder use .NET
> > instead of EasySOAP, which is PowerBuilder's implementation of
 SOAP.
> > Sadly, my organization will not allow .NET so I am limited. This  
> is why
> > I am using plain vanilla SOAP. The client creates a SOAP message
 and
> > calls the service. My web service doesn't do anything with SOAP  
> itself.
> > It is just a Java class which generates XHTML and returns it. The  
> SOAP
> > container on the server (Axis2) takes care of converting the  
> string to a
> > SOAP message response. Somewhere in that process of taking my  
> string and
> > converting it to a SOAP message is where it encodes it.
> >
> > I did try changing the wsdl to have the return type be  
> base64Binary but
> > that did not keep the XHTML from being encoded. I was hoping there
  
> would
> > be a simple change I can make to the wsdl to tell SOAP to ignore
 the
> > content of the return and don't encode it but maybe there isn't an
  
> easy way.
> >
> > I will look further into MTOM. Maybe I can at least get it working
  
> via a
> > Java client. In the meantime, any other ideas from you or anyone  
> else
> > would be greatly appreciated!
> >
> > Thanks,
> > Scott
> >
> > ----- Original Message ----
> > From: Paul Fremantle <[EMAIL PROTECTED]>
> > To: [email protected]
> > Sent: Monday, January 14, 2008 12:07:56 PM
> > Subject: Re: Process SOAP message containg XHTML
> >
> > One option would be to treat the data as a binary message and use  
> MTOM
> > to send it. This should reduce the XML processing and will also  
> avoid
> > any encoding issues.
> >
> > Paul
> >
> > On Jan 14, 2008 3:36 PM, Scott Malinowski <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >  >
> >  > Hello,
> >  >
> >  > This is probably a SOAP question more than an AXIS2 question. If
> > there is a
> >  > better place to post my question please let me know.
> >  >
> >  > I have written a SOAP web service using AXIS2. It returns XHTML
  
> as a
> > string.
> >  > The problem is on the client side. It takes several minutes to
> > process the
> >  > response, which is only a few hundred kilobytes. My research on
  
> this has
> >  > pointed me to the fact that the XHTML within the SOAP response  
> has become
> >  > encoded (e.g. '<' has become '&lt;') and that it is taking  
> awhile for
> > this
> >  > data to be converted back. It only takes a second or so for the
  
> client to
> >  > send the request and receive a response. The time delay comes  
> when I call
> >  > getSOAPBody() on the client. I have tried wrapping the XHTML in
> > '<<![CDATA['
> >  > and ']]>' but to no avail (it is still encoded in the SOAP  
> response).
> > How do
> >  > I return XHTML so that Axis2 and/or SOAP ignores the XHTML when
> > building the
> >  > response and leaves it unencoded?
> >  >
> >  > Thanks,
> >  > Scott
> >  >
> >  >  ________________________________
> >  > Looking for last minute shopping deals? Find them fast with  
> Yahoo!
> > Search.
> >
> >
> >
> > --
> > Paul Fremantle
> > Co-Founder and VP of Technical Sales, WSO2
> > OASIS WS-RX TC Co-chair
> >
> > blog: http://pzf.fremantle.org
> > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
 <http://www.wso2.com 
> >
> >
> >  
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>
> >
> >
> >
> >  
>
 ------------------------------------------------------------------------
> > Be a better friend, newshound, and know-it-all with Yahoo! Mobile.
  
> Try
> > it now.
> >
 
<http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
> >  >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  
> Try it now.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







      
____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

Reply via email to