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(SchemaTypeLoa
> derBase.java:370)
> at
> com.cisco.musebox.schemas.box.BoxDocument$Factory.parse(Unknown Source)
> at
> com.cisco.musebox.client.proxy.SimpleEquipmentClient.equipmentOperation(
> 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]
