The reasons that the client invoke() returns the wrapper element are:
1. Some WS-* operations use the wrapper element to return data, and
there's nothing that prevents you from doing the same:
<MyOperationResponse>some value</MyOperationResponse>
vs.
<MyOperationResponse>
<MyValue>some value</MyValue>
</MyOperationResponse>
The above are the same, and to account for both we need the wrapper.
2. Some WS-* operations have more than one return value. An example would
be WSN Subscribe.
At any rate, our original idea is that invoke() would be hidden from the
user, who would just use the generated methods. The problem comes with
complex types on the client side - wsdl2java can't generate code for them
without knowing what the class/interface should be, and providing that
info would require some kind of custom WSDL annotation.
"Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 11/28/2006
08:50:52 PM:
> Thanks Dan,
> I'll try your suggestion below. I think that's part of the confusion.
> If my server code doesn't not need to specify the wrapper element, I
> would also expect my client code to receive the exact same data that my
> server code produced. Meaning, the client code should not need to deal
> with the wrapper element, too. So, if Muse autowraps the result of the
> server operation, it would be nice if it also removed the wrapper when
> handing the result to the client. Otherwise, client developers will be
> confused with what to do with the wrapper.
>
> It would also be helpful to others if (at some future point) the samples
> showed this kind of work. I've been doing a lot of trial and error to
> figure out what code to write on both the server and client,
> particularly when dealing with complex objects, because there's little
> or no detailed samples/patterns to follow in these areas. I do
> appreciate the hard work you guys are doing so far though :)
> -Vinh
>
>
>
> -----Original Message-----
> From: Daniel Jemiolo [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 22, 2006 2:43 PM
> To: [email protected]
> Subject: RE: changed capability result data
>
> It looks like your stack trace is because you're feeding the wrapper
> element to XmlBeans instead of the Box element... right? Shouldn't it
> be:
>
> public BoxType equipmentOperation(String param1)
> throws SoapFault, Exception
> {
> Element body =
> XmlUtils.createElement(IEquipmentCapability.OP_QNAME, param1);
> Element response = invoke(IEquipmentCapability.OP_URI, body);
>
> // this gets the <Box/>, which is what XmlBeans should parse...
> Element boxXML = XmlUtils.getFirstElement(response);
>
> BoxDocument doc = BoxDocument.Factory.parse(boxXML);
> return doc.getBox();
> }
>
>
> Or am I missing something?
>
> I honestly don't know why the default namespace is being added in. If
> you turn on SOAP tracing on the server side (use the nightly build and
> set the log level to 'FINE'), the SOAP messages in muse.log will show
> you what Muse passes to Axis2 right before control goes back to Axis2.
> The XML should be the same that you provided. If it's not, then Muse has
> a problem; if so, it's an Axis2 or XML parser problem.
>
> Dan
>
>
> "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 11/22/2006
> 02:35:04 PM:
>
> > Thankyou Dan,
> >
> > 1) I'm using XmlBeans to generate pojo classes from xsd's, and I use
> > them both on the server and client. On the server, the bean has a
> > mechanism for getting the xml representation of itself, which I then
> > pass to Muse. On the client, the same bean can be recreated from the
> > xml. The main problem I'm getting is on the server side when my bean
> > tries to parse the incoming xml. For one, the xml has the "response"
> > wrapper, so I have to find a way to use the child node below it. And
> > second, the child node's xml representation has changed from what was
> > passed on the server side.
> >
> > Here's the server code:
> >
> > public class EquipmentCapability extends AbstractCapability implements
>
> > IEquipmentCapability {
> > public Element equipmentOperation(String param1) throws Exception
> > {
> > // Get the EPR id of this capability's resource.
> > // For now, assume that a parameter value is set which
> > contains the EPR ID.
> > MessageHeaders headers =
> > getEnvironment().getAddressingContext();
> > EndpointReference epr = headers.getToAddress();
> > String eprID = epr.getParameters()[0].getTextContent();
> >
> > // Store the EPR id in the response object so that we can
> > identify which resource EPR this capability was invoked on.
> > BoxDocument doc = BoxDocument.Factory.newInstance();
> > BoxType type = doc.addNewBox();
> > type.setName("EPR ID: " + eprID);
> >
> > System.out.println("--XmlUtils.toString(doc.newDomNode()):\n"
> > + XmlUtils.toString(doc.newDomNode()));
> > return XmlUtils.getFirstElement(doc.newDomNode());
> > }
> > }
> >
> > Here's the client code:
> >
> > public class SimpleEquipmentClient extends WsResourceClient {
> > public BoxType equipmentOperation(String param1)
> > throws SoapFault, Exception
> > {
> > Element body =
> > XmlUtils.createElement(IEquipmentCapability.OP_QNAME, param1);
> > Element response = invoke(IEquipmentCapability.OP_URI, body);
> > System.out.println("response:\n" +
> > XmlUtils.toString(response));
> >
> > //EquipmentOperationResponseDocument doc =
> > EquipmentOperationResponseDocument.Factory.parse(response);
> > //BoxType type = doc.getEquipmentOperationResponse().getBox();
> > BoxDocument doc = BoxDocument.Factory.parse(response);
> > BoxType type = doc.getBox();
> >
> > return type;
> > }
> > }
> >
> > Here's the server console output:
> >
> > --XmlUtils.toString(doc.newDomNode()):
> > <?xml version="1.0" encoding="UTF-8"?> <box:Box
> > xmlns:box="http://cisco.com/musebox/schemas/box";>
> > <box:name>EPR ID: MuseResource-2</box:name> </box:Box>
> >
> > Here's the client console output:
> >
> > 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="http://schemas.xmlsoap.org/wsdl/";
> > xmlns:box="http://cisco.com/musebox/schemas/box";>
> > <box:name>EPR ID: MuseResource-2</box:name>
> > </Box>
> > </muse-op:EquipmentOperationResponse>
> >
> > org.apache.xmlbeans.XmlException: Element
> > [EMAIL PROTECTED]://cisco.com/musebox/cap/equip is not a
>
> > valid [EMAIL PROTECTED]://cisco.com/musebox/schemas/box document or a valid
> > substitution.
> > at
> >
> org.apache.xmlbeans.impl.store.Locale.autoTypeDocument(Locale.java:322)
> > at
> >
> org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1384)
> > at
> >
> org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1363)
> > at
> > org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeL
> > oa
> > derBase.java:370)
> > at
> > com.cisco.musebox.schemas.box.BoxDocument$Factory.parse(Unknown
> Source)
> > at
> > com.cisco.musebox.client.proxy.SimpleEquipmentClient.equipmentOperatio
> > n(
> > SimpleEquipmentClient.java:42)
> > at
> >
> com.cisco.musebox.client.test.ResourceFacadeTest.run(ResourceFacadeTest.
> > java:70)
> > at
> > com.cisco.musebox.client.test.Main.testResourceFacade(Main.java:44)
> > at com.cisco.musebox.client.test.Main.main(Main.java:23)
> >
> >
> > In the client code, the EquipmentOperationResponseDocument object that
>
> > I commented out is also created from XmlBeans using the resource wsdl.
>
> > If I use this object instead to parse the response, I get a null
> > BoxType reference from it because it seems to be unable to parse out
> > the <Box> element from the xml. I suspect this is because XmlBeans
> > has some issues with certain usage patterns of namespaces and
> > prefixes. But, if the xml was received the same way it was created
> > from my bean, it should be able to parse it correctly. So the issue
> > is why it is changing from the server to the client. If I need to, I
> > can try to trace the core code at some point later to know for sure
> > where the problem is happenning.
> >
> > 2) To get around this problem, I can create serializers for each of
> > the pojo types. I would like to find a generic way to do it though,
> > if I can get away from explicitly identifying each serializer class in
>
> > the muse.xml somehow. If not, I may have to do just that, and
> > hopefully maintenence won't get too difficult in the long run when
> > more types are created.
> >
> >
> > -----Original Message-----
> > From: Daniel Jemiolo [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, November 22, 2006 7:15 AM
> > To: [email protected]
> > Subject: RE: changed capability result data
> >
> > 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
> >
> > ---------------------------------------------------------------------
> > 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]
>
> ---------------------------------------------------------------------
> 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]
