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]
