1. I suppose Muse does strip your wrapper element out, but it's not really expecting it in the first place - the Java return type is supposed to be serialized and then added to the response message, so the user isn't expected to handle the wrapper SOAP. If you really want to handle the wrapper SOAP you can create a custom MessageHandler for this, but given the other behavior, I don't think this would solve your problem.
2. Here we have to look at what Java requires. Web services allow for multiple return values, but Java does not; if we want to return multiple values in Java, we either use a Collection or, if the values are all related (usually they are), we made a simple wrapper class. Since SOAP + Collections has never been well-defined or especially interoperable, I suggest the latter. Make a wrapper type that has the N elements you want, and create a Java class from that. The Java class can then have getter methods to expose the different fields. 3. The Muse code is pretty sensitive to the issue of prefix and namespace combinations - we don't like to modify anyone's prefix/namespaces because that can make some parts of a WSRF-based message unresolvable. Axis2 used to do this and we had a big hack in place to workaround it; they've fixed it now, so that means both Muse and Axis2 should be leaving your XML alone. On the client side, Muse just reads in your XML as bytes from an InputStream and uses XmlUtils.createDocument() to make the DOM Element (which just uses Xerces, there's not pre-modification). Where exactly is the XmlBeans stuff being used? Just client side? Or on the server side? Have you had any luck creating the Elements with XmlUtils.createELement() vs. building a string literal? 4. Is your XmlBeans code boilerplate-like? That is, does look the same whether you're serializing a Box or some other custom type? If so, let me know what the code looks like (I'm not an XmlBeans user), and I can suggest a way to fit it into the Serializer framework so that supporting many types isn't such a burden but you still get the benefit of a real Java programming model. Dan "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 11/21/2006 09:18:01 PM: > Hi Dan, > Few questions... > > 1) If I don't wrap my result in a <EquipmentOperationResponse/> element, > I can see that Muse does automatically add that wrapper. So if I do > happen to add the wrapper myself, is Muse stripping mines out and > putting another one on? > > 2) If I don't use the response element, and my wsdl is updated to define > a response containing a sequence of multiple elements, how would those > elements be returned in a single Element object and still be > auto-wrapped properly in the response? Should the convention be to > always return a single object? In this case, a sequence of only one > object, although the object itself can be a composite. > > 3) I've also tested without using the response wrapper, but it is still > addding the <Box xmlns:equ="http://cisco.com/musebox/cap/equip";> node > right under the response node, above the <equ:Box> node. This inserted > node is not in the hardcoded xml I used to create the response, so I'm > not sure where it's coming from. Now, looking at my wsdl definition, > I'm not sure what the correct xml should look like. I need to figure > out if my xmlbean is the issue or not. > > 4) Specifying a serializer in muse.xml for each custom type (i.e. Box) > is probably not ideal for us because our underlying system has a large > set of custom objects that can be passed around. For now, we want to > try to stick to passing the Element representation of our objects since > we're using XmlBeans for the xml serialization. > > > -----Original Message----- > From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 21, 2006 3:01 PM > To: [email protected] > Subject: RE: changed capability result data > > Not sure why the prefix is being dropped from <Box/>, but I'm guessing > it was the same code that added the Axis2 namespace (in the Axis2 > engine). > The response element is created by Muse (<EquipmentResponse/>), so you > don't need to include that. Just return the actual return value and not > the wrapper around it. Try this first to see if it solves the problem. > > If that works, I would also propose the following to make things a bit > more efficient and separate the XML serialization from your capability > logic: > > 1. Change your method signature and implementation to return a Box > object: > > public Box equipmentOperation() > { > Box box = ... // do work, make box > > return box; > } > > 2. Add the following to muse.xml (under the root element): > > <custom-serializer> > <java-serializable-type>your.package.name.Box</java-serializable-type/> > > <java-serializer-class>your.package.name.BoxSerializer</java-serializabl > e-class> > </custom-serializer> > > 3. Add the following class to the code that wsdl2java generated for you: > > package your.package.name; > > import javax.xml.namespace.QName; > > import org.w3c.dom.Element; > > import org.apache.muse.core.serializer.Serializer; > > public class BoxSerializer implements Serializer { > public Class getSerializableType() > { > return Box.class; > } > > public Object fromXML(Element xml) > { > // use XmlBeans-generated classes here > } > > public Element toXML(Object obj, QName qname) // qname will be > box:Box > { > // use the XmlBeans-generated classes here > } > } > > > Once you've finished the Serializer class, just recompile/rebuild and > run > the application again. On the client side, you can use the BoxSerializer > > to convert the response XML to a Box object. > > > > "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 11/21/2006 > 05:11:44 PM: > > > Reposting again in plain text since Outlook is messing up the > namespaces > > in the code... > > > > > > There seems to be a problem with the way Muse returns capability > results > > to the client. For example, my capability returns a custom type > wrapped > > in an Element. The xml contains proper namespaces and prefixes. But, > > when my test client receives the Element, the xml format has been > > changed. I'm using XmlBeans for the serialization, and I'm running > into > > problems on the client side. Am I doing something wrong? > > > > My wsdl is as follows: > > <xsd:schema > > elementFormDefault="qualified" > > targetNamespace="http://cisco.com/musebox/cap/equip";> > > <xsd:element name="EquipmentOperation" type="xsd:string" /> > > <xsd:element name="EquipmentOperationResponse"> > > <xsd:complexType> > > <xsd:sequence> > > <xsd:element name="Box" type="bx:BoxType"/> > > </xsd:sequence> > > </xsd:complexType> > > </xsd:element> > > </xsd:schema> > > > > My capability code is as follows: > > String xml = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>" > > + "<equ:EquipmentOperationResponse > xmlns:equ=\"http://cisco.com/musebox/cap/equip\";>" > > + "<equ:Box>" > > + "<box:name> > xmlns:box=\"http://cisco.com/musebox/schemas/box\";>EPR ID: > MuseResource-2</box:name>" > > + "</equ:Box>" > > + "</equ:EquipmentOperationResponse>"; > > Document xmlDoc = XmlUtils.createDocument(xml); > > System.out.println("xmlDoc toString:\n" + > > XmlUtils.toString(xmlDoc)); > > return XmlUtils.getFirstElement(xmlDoc); > > > > My client code is: > > Element body = > XmlUtils.createElement(IEquipmentCapability.OP_QNAME, param1); > > Element response = invoke(IEquipmentCapability.OP_URI, body); > > System.out.println("response:\n" + XmlUtils.toString(response)); > > > > Here's a snippet of the server side output: > > xmlDoc toString: > > <?xml version="1.0" encoding="UTF-8"?> > > <equ:EquipmentOperationResponse > xmlns:equ="http://cisco.com/musebox/cap/equip";> > > <equ:Box> > > <box:name > xmlns:box="http://cisco.com/musebox/schemas/box";>EPR ID: > MuseResource-2</box:name> > > </equ:Box> > > </equ:EquipmentOperationResponse> > > > > Here's a snippet of the client incoming trace results: > > [CLIENT TRACE] SOAP envelope contents (incoming): > > ... > > <soapenv:Body> > > <muse-op:EquipmentOperationResponse > xmlns:muse-op="http://cisco.com/musebox/cap/equip"; > xmlns:tns="http://ws.apache.org/axis2";> > > <Box xmlns:equ="http://cisco.com/musebox/cap/equip";> > > <equ:Box> > > <box:name > xmlns:box="http://cisco.com/musebox/schemas/box";>EPR ID: > MuseResource-2</box:name> > > </equ:Box> > > </Box> > > </muse-op:EquipmentOperationResponse> > > </soapenv:Body> > > </soapenv:Envelope> > > > > My client code outputs this result: > > response: > > <?xml version="1.0" encoding="UTF-8"?> > > <muse-op:EquipmentOperationResponse > > xmlns:muse-op="http://cisco.com/musebox/cap/equip"; > xmlns:tns="http://ws.apache.org/axis2";> > > <Box xmlns:equ="http://cisco.com/musebox/cap/equip";> > > <equ:Box> > > <box:name > xmlns:box="http://cisco.com/musebox/schemas/box";>EPR ID: > MuseResource-2</box:name> > > </equ:Box> > > </Box> > > </muse-op:EquipmentOperationResponse> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
