Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

CDATA  RSS feed

 
Kevin Eddy
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've got an any element that I have to put an xml string on. When I use a jaxws client and have: myTransmission.setAny(myXmlString). I get the following error:
java.lang.String cannot be cast to javax.xml.bind.JAXBElement
If I use a JAXBElement and do
JAXBElement element = new JAXBElement(new QName("myQname"), String.class, myXmlString);
Then when I get to the host, the myXmlString is escaped with a CData tag.
Is there anyway to tell JaxB to just take a string, not modify it, just send it as is without screwing it up?
 
Paul Clapham
Sheriff
Posts: 22468
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why do you consider the use of a CDATA section to represent a text node to be "screwing it up"?
 
Kevin Eddy
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:Why do you consider the use of a CDATA section to represent a text node to be "screwing it up"?


Good question. The short answer is I need the xmlString to unmarshal in to a schema object. In my case, the service is wsdl first. The schemas are detached, decoupled if you will, from the wsdl. So, the wsdl never has to change, but the schemas can and do change about once a year. There is an existing axis1 service in place for this application and I have been looking at what it would take to move it to Jax-Ws.

I've been trying to test a "ported to jax-ws" portion of this web service with a jax-ws client. What I did was use a tool called xmlSpy to auto generate my xml. I copied that as a string into my test client. I need the string to go over as-is so that I can use it to create a generated schema object. But since it's wrapped in a CDATA section, then that's making it a lot more complicated for me to deal with. Not all clients of this service may send data to the host wrapped in CData. Anyway, at this point it seems to be more of a client issue than anything that's happening on my host.

If you're wondering, the wsdl is predefined. I'm not at liberty to change it and include the schemas. Although, if that were the case, this would all be much simpler. And lastly, realize that I've only been doing webservices for about 5 months. So if I say something that doesn't sound right or is just wrong feel free to correct me. At this point my pride is at the door.
 
Paul Clapham
Sheriff
Posts: 22468
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I wouldn't classify myself as a Web Services expert by any means. I'm just looking at it this way: in an XML document, it's immaterial whether a text node is a CDATA section or not. XML-processing software is supposed to respect that rule, and all of those things you mention are XML-processing software. So it shouldn't matter at all. And usually the parsers will take care of dealing with the text nodes anyway.

Are you finding that there is some software component in your Web Services stack which rejects documents because they have text nodes which use CDATA sections?
 
Kevin Eddy
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:I wouldn't classify myself as a Web Services expert by any means. I'm just looking at it this way: in an XML document, it's immaterial whether a text node is a CDATA section or not. XML-processing software is supposed to respect that rule, and all of those things you mention are XML-processing software. So it shouldn't matter at all. And usually the parsers will take care of dealing with the text nodes anyway.

Are you finding that there is some software component in your Web Services stack which rejects documents because they have text nodes which use CDATA sections?


Paul, that's a good question again. Unfortunately I only have time to say that I will reply to this question more in depth in a couple of days. My wife is having surgery tomorrow and I'm a bit strapped at the moment. Thanks sooooo much for asking in and I will address this later. I just popped on for a few minutes to check my email.
 
Kevin Eddy
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kevin Eddy wrote:
Paul Clapham wrote:I wouldn't classify myself as a Web Services expert by any means. I'm just looking at it this way: in an XML document, it's immaterial whether a text node is a CDATA section or not. XML-processing software is supposed to respect that rule, and all of those things you mention are XML-processing software. So it shouldn't matter at all. And usually the parsers will take care of dealing with the text nodes anyway.

Are you finding that there is some software component in your Web Services stack which rejects documents because they have text nodes which use CDATA sections?


Paul, I could work with the CDATA and find some way around it I'm sure. The problem here is that not all clients may send the message over as CDATA. Nor should they be required to since it's straight up xml.

What I really need to know is this. Does jax-ws have a mechanism in place to set a string, in this case it's straight up xml, without wrapping it in a Qname tag and without wrapping it in CDATA. Where the xml string matches a schema which is detached from the wsdl by way of the "any" element.

In the axis1 version of this service, foo.get_any().toString yields an xmlString. The xmlString is used to parse the BarDocument as follows: BarDocument.Factory.parse(xmlString).

I'm having a heckuva time porting this functionality to Jax-ws. Or finding anything remotely like it with the jax-ws api. Theoretically, If I could pull the string off, I could parse into a xmlBeans object. Even though jax-ws supports only jaxb, it seems like this could work. Also, and I'm not trying to turn this into some kind of war between axis and jax-ws, I simply don't know enough about either yet to do that. What I have noticed is that regarding the particular schemas that I've been given, xmlBeans seems to handle the compilation more gracefully. I say that because when I dig down into the code to pull of a specific object I get the following:
"You are getting this "catch-all" property because of the following reason: The field name "FinancialTransaction" is used by two different parts of a schema."
As a result of that, the only method available is the getContent() method which returns a JAXBElement.

XmlBeans seems to handle this without giving me any grief. Anyway, I think for now I'm going to have to stick with the axis1 version of this app. I've spun my wheels for a week just trying to wrap my head around how jax-ws deals with getAny and setAny. I will have to put the jax-ws conversion on the backburner for now. That being said, all suggestions welcome.

For app's that I can "code first", I'll use jax-ws. I've written one and it worked out nicely. I'm just beginning to think that jax-ws may not be a good choice for this particular app.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!