This week's giveaways are in the MongoDB and Jobs Discussion forums. We're giving away four copies of Mongo DB Applied Patterns and 4 resume reviews from Five Year Itch and have the authors/reps on-line! See this thread and this one for details.
strange soap message creation with plain old java code, any suggestions?
Joined: Apr 09, 2010
ok, i am trying to create a soap message, and for the most part my code works great. but I am getting a small error when I set 1 of the soap body attributes and was wondering if anyone could see what was going on here.
the "body" created by the code below....(this is just the body part)....is correct except for attribute 1 ("att1") is put on the child element ("child1") instead of its parent. (even though I add the attribute to the parent element)
further below, I have an element named "proximity" where I am adding an attribute to it, this works fine.
KEY QUESTION: why do you suppose that it is putting my first attribute on the child of the element in which that attribute is intended?
(g1c1 = grandchild, gg1g1c1 = great grandchild, ggg1gg1g2c1 = great great grandchild)
And if you don't *need* the return value of the method then don't save it--it just obfuscates what's really happening.
Joined: Apr 09, 2010
creating a new QName with your attribute details must be a better way, then using the addAttribute function on an element.
(still weird why I was able to do this with one of my grand child elements "proximity", maybe I should turn this into a QName too?)
and my variable names could be revised, but will have to rethink the naming scheme, I was trying to come up with something that would represent a sort of "family tree" of elements if you will...
where: ggg1 = 1st great great grand of parent in body, gg2 = 2nd great grand of parent on body, g1 = 1st grand of parent in body....ggg1gg2g1 etc...
but that obviously was confusing, to others.
and you're right, if i'm not going to use the return value of a function, that I should just leave it off, thanks
[quote=Lavanya Halliwell]and my variable names could be revised, but will have to rethink the naming scheme, I was trying to come up with something that would represent a sort of "family tree" of elements if you will...[/quote]
But it's not "just" a simple tree: the descendants are (XML) elements of a particular type, and should be named accordingly: name them the same way you're naming your XML elements--otherwise the Java code becomes essentially meaningless.
Any time there's positional naming, if the positioning ever changes even a little bit, the name is rendered incorrect at best, willfully misleading at worst.
Joined: Apr 09, 2010
thanks for the naming scheme tips, I put a few into practice. maybe I got it sort of right this time. (this way it does represent the element better)
If the issue is not resolved, then consider this:
In the original code, you had this line:
This would result in:
- An element <IPhoneAppServiceProcessRequest> being added as a child to the body element.
- An attribute att1 being added to the <IPhoneAppServiceProcessRequest> element, that is the element returned from the method call:
- The SOAPElement object refering to the <IPhoneAppServiceProcessRequest> would be assigned to the variable parent.
This, since this is the SOAPElement object returned from the addAttribute method invocation.
I think you solved the problem by cleaning up your code. Thus, writing readable code not only helps others, but also yourself!
The thing is that the original code *did* add an "xmlns" attribute to the parent, and its attribute was correct in the Java object. Once the message was serialized, though, the IPhoneAppServiceProcessRequest element had an empty xmlns attribute value, and its child, serviceRequest, had the xmlns attribute I expected to see in the IPhoneAppServiceProcessRequest element.
If we check the IPhoneAppServiceProcessRequest element's "xmlns" attribute in Java it's correct right after assigning it. I'm not actually sure *why* the original behavior is exhibited--I'd have to dig into either the serialization code or... not sure where else. It didn't make much sense to me, but using the QName thing produced the correct output.
I don't know why the original code doesn't work, though--but I'm not a big SOAP user (or when I am, I make my XML with Groovy :)