Hi Tomek, can I get a answer for this ? I'm trying to send XML as string parameter. One of my clients requires that. See my previous post, that's the way they designed their web service... Now I tried to put it as CDATA as well (what Marco suggested, thanks) but it didn't worked either.
For example here is an outgoing SOAP message from the XFire debugging: 11-Jul-2007 11:21:02 AM org.codehaus.xfire.util.LoggingHandler invoke INFO: <?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> <soap:Body> <ns1:putDevice xmlns:ns1="http://someurl";> <ns1:Username>someusername</ns1:Username> <ns1:Password>somepassword</ns1:Password> <ns1:deviceMsgDoc><![CDATA [<deviceMsgDoc><creationDate>2007-06-21T11:32:21.000000-04:00</creationDate><sequenceNumber>1</sequenceNumber><version>test</version><deviceMsgs><deviceMsg><customerId>54321</customerId><devices><device><sku>2345</sku><BECSRefId>4</BECSRefId><serialNumber>2345</serialNumber><MACAddress>2345</MACAddress><gatewayPassword>2345</gatewayPassword></device><device><sku>1234</sku><BECSRefId>5</BECSRefId><parentDeviceBECSRefId>4</parentDeviceBECSRefId><serialNumber>1234</serialNumber><MACAddress>1234</MACAddress><gatewayPassword>1234</gatewayPassword></device></devices></deviceMsg></deviceMsgs></deviceMsgDoc>]]></ns1:deviceMsgDoc> </ns1:putDevice> </soap:Body> </soap:Envelope> expanded the string for deviceMsgDoc is like this: <deviceMsgDoc><creationDate>2007-06-21T11:32:21.000000-04:00</creationDate><sequenceNumber>1</sequenceNumber><version>test</version><deviceMsgs><deviceMsg><customerId>54321</customerId><devices><device><sku>2345</sku><BECSRefId>4</BECSRefId><serialNumber>2345</serialNumber><MACAddress>2345</MACAddress><gatewayPassword>2345</gatewayPassword></device><device><sku>1234</sku><BECSRefId>5</BECSRefId><parentDeviceBECSRefId>4</parentDeviceBECSRefId><serialNumber>1234</serialNumber><MACAddress>1234</MACAddress><gatewayPassword>1234</gatewayPassword></device></devices></deviceMsg></deviceMsgs></deviceMsgDoc> On the server side I'm being told that the parameter is missing, so that is probably because my input string is not in correct format. Is the XFire debugging parsing the outgoing SOAP in order to present a nice view of that SOAP message (so in other words the outgoing SOAP is correct using < > tags), or the outgoing SOAP is literally like that with the open < tag and close > tag interpreted as < respective > (if this is the case then that's my problem because I have to send a valid xml converted to a string ...) ??? I tried to find the answer to that on the wiki but to no avail. Thanks prematurely, Dragos On Thu, 2007-28-06 at 21:33 +0200, Marco Buss wrote: > Try to wrap the element as CDATA: <![CDATA[<your-string>]]> i dont know > but it can help. > > Regards > Marco > > Dragos Pavel schrieb: > > Hi All, > > > > I have to develop a client web service to consume somebody else web > > service. The way they implemented their web service is that they didn't > > created proper data types for all the elements in the wsdl; therefore > > for some methods/functions I have to provide xml data converted to one > > string as a parameter! I know this design will not work in XFire when > > developing your own web service to be published, but what about for just > > client web services = it is possible to send xml data converted to one > > string as they require ? > > > > Thanks, > > Dragos > > > > > > On Sat, 2007-16-06 at 01:38 -0700, Gert Vanthienen wrote: > > > >> Tomek, > >> > >> It is indeed the input format of the XML message that causes this problem. > >> We are not sending XML as String, but as DOMSource/StaxSource and it > >> appears > >> our implementation of the latter somehow causes the problem. Thank you for > >> your help: we still have to solve the problem but now at least we know > >> where > >> to look. > >> > >> Regards, > >> > >> Gert > >> > >> > >> Tomek Sztelak wrote: > >> > >>> My guess (but i only took a peek at stactrace, so could be wrong) is > >>> that you are trying to send XML as string parameter which confuses xml > >>> parser. > >>> > >>> On 6/15/07, Gert Vanthienen <[EMAIL PROTECTED]> wrote: > >>> > >>>> L.S., > >>>> > >>>> I'm trying to resolve some issues in Apache ServiceMix, all of which are > >>>> throwing IllegalStateExceptions, stating that the current event or state > >>>> are > >>>> something else than expected (e.g. The current event is not START_ELEMENT > >>>> but 7). > >>>> > >>>> The exceptions are being raised inside XFire. I'm quite sure it is an > >>>> error in ServiceMix somewhere, it is not mentioned on the XFire mailing > >>>> lists. I have also tried upgrading XFire to the latest version (1.2.6) > >>>> but > >>>> that causes even more exceptions of the same kind (cfr. footnote -- > >>>> SM-964) > >>>> > >>>> Can someone give me a brief explanation on what this exception means and > >>>> what can be causing it? > >>>> > >>>> Thank you, > >>>> > >>>> Gert Vanthienen > >>>> > >>>> > >>>> P.S. The full stack traces are available in ServiceMix's JIRA at: > >>>> - https://issues.apache.org/activemq/browse/SM-964 > >>>> - https://issues.apache.org/activemq/browse/SM-787 > >>>> - https://issues.apache.org/activemq/browse/SM-960 > >>>> > >>>> -- > >>>> View this message in context: > >>>> http://www.nabble.com/What-does-IllegalStateException-%28current-event-is-not-...%29-mean--tf3926908.html#a11136515 > >>>> Sent from the XFire - User mailing list archive at Nabble.com. > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe from this list please visit: > >>>> > >>>> http://xircles.codehaus.org/manage_email > >>>> > >>>> > >>>> > >>> -- > >>> ----- > >>> When one of our products stops working, we'll blame another vendor > >>> within 24 hours. > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe from this list please visit: > >>> > >>> http://xircles.codehaus.org/manage_email > >>> > >>> > >>> > >>> > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this list please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
