Thanks Dan,
Yep, I've been using your suggested code pattern in my previous tests.
I serialize my object to xml on the server, and then deserialize back to
my object on the client. The only difference is that since my schemas
are generated using XmlBeans, the beans have similar toXml() and
fromXml() methods, so I don't need a custom serializer.
Now, I've tried the code pattern where I implement custom serializers.
I also take it to the next step by having Muse call the serializers
directly when I pass the custom object as is, instead of as an Element.
The goal is to shield the client developer from having to deal with
serializers directly because the framework should do that automatically.
For example, after having created a CarTypeSerializer and specified it
in muse.xml, my server code looks like:
public class CarCapability extends AbstractCapability implements
ICarCapability
{
public CarType carOperation(String make, String model, String
color) throws Exception
{
CarDocument doc = CarDocument.Factory.newInstance();
CarType type = doc.addNewCar();
type.setMake(make);
type.setModel(model);
type.setColor(color);
return type;
}
}
My client code looks like:
public class SimpleResourceClient extends AbstractResourceClient
{
public Object testCarOperation(String make, String model, String
color)
throws SoapFault
{
String uri = "http://cisco.com/musebox/simple/car";;
String requestOp = "CarOperation";
String responseOp = "CarOperationResponse";
String pfx = "car";
QName[] paramNames = new QName[]
{ICarCapability.PARAM1_QNAME, ICarCapability.PARAM2_QNAME,
ICarCapability.PARAM3_QNAME};
Object[] paramValues = new Object[] {make, model, color};
ReflectionProxyHandler handler = new
ReflectionProxyHandler();
handler.setAction(uri + "/" + requestOp);
handler.setRequestName(new QName(uri, requestOp, pfx));
handler.setRequestParameterNames(paramNames);
handler.setResponseName(new QName(uri, responseOp, pfx));
handler.setReturnType(CarType.class);
SerializerRegistry registry =
SerializerRegistry.getInstance();
registry.registerSerializer(CarType.class, new
CarTypeSerializer());
CarType response = (CarType)invoke(handler, new Object[]
{body});
return response;
}
}
This pattern seems to work, too, but when Muse calls
CarTypeSerializer.fromXml() on the client side, I ran into the same
problem again as in my previous postings with the xml element namespace
mismatch issue. So it's unable to deserialize back to a CarType. I
assume once we resolve this namespace mismatch issue at some point, my
serializer will work properly.
-----Original Message-----
From: Daniel Jemiolo [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 29, 2006 1:01 PM
To: [email protected]
Subject: Re: custom serialization sample code?
The easiest way to do this (meaning, the way that involves modifying as
little of the generated code as possible) would be to take the code for
boxOperation() as generated and add to the end of it like so:
Element response = (Element)invoke(...); // last line of generated code
Element boxXML = XmlUtils.getFirstElement(response);
Serializer boxSer =
SerializerRegistry().getInstance().getSerializer(BoxType.class);
return (BoxType)boxSer.fromXML(boxXML);
Then, I'd add the BoxSerializer like so:
static
{
SerializerRegistry reg = SerializerRegistry.getInstance();
reg.registerSerializer(BoxType.class, new BoxSerializer()); }
The serializer lookup and call to fromXML() is normally done by the
invoke() method (notice it returns an Object, not an Element). However,
this only happens for types that it knows about during code generation.
If you look at the private arrays that are generated in the client,
you'll see a bunch of info that is used to make the right call and
parsing decisions in invoke(). Rather than have you modify that stuff,
though, I think you're better off trying the code above.
"Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 11/28/2006
08:36:27 PM:
> Does anyone have sample code that shows how to return a custom type
> from a capability operation, and then how to retrieve that object from
> the client side?
>
> For example, I have a BoxType as the return value of a capability
> method. I have a custom BoxTypeSerializer and specified it in
muse.xml.
> In the server trace, I see the xml data being passed ok to the client.
> But, in myclient code, I'm not sure what to write in order to retrieve
> this BoxType object properly.
>
> The apache-httpd sample only shows how to retrieve a custom type as a
> resource property by calling WsResourceClient.getPropertyAsObject().
> But, this can't be used when trying to get the custom type as a return
> value of an operation.
>
> My client proxy class implements AbstractResourceClient. The only
> methods available for calling resource operations are
> invoke(String,Element) and invoke(ProxyHandler,Object[]). The first
> method returns an xml Element, which is not what I want because I'm
> expecting a BoxType object. The second method doesn't make sense on
> the client side because the client would not know the reflection info
> to pass in the call (which must be specified to
> ReflectionProxyHandler, the only implementation of the ProxyHandler
> interface). I think ideally, this should all be hidden from the
> client, and the only thing the client needs to know is the resource
> EPR, and the operation name and parameters.
>
> Here's my server code (using XmlBeans for serialization):
> public class BoxCapability extends AbstractCapability implements
> IBoxCapability
> {
> public BoxType boxOperation(int width) throws Exception
> {
> BoxDocument doc = BoxDocument.Factory.newInstance();
> BoxType type = doc.addNewBox();
> type.setWidth(BigInteger.valueOf(width));
> type.setHeight(BigInteger.valueOf(width));
> return type;
> }
> }
>
> Here's my incomplete client code:
> public class SimpleResourceClient extends AbstractResourceClient
> {
> public BoxType testBoxOperation(int width) throws SoapFault
> {
> Element body =
> XmlUtils.createElement(IBoxCapability.OP_QNAME, new Integer(width));
>
> BoxType response = ... // what do I write here???
>
> return response;
> }
> }
>
>
---------------------------------------------------------------------
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]
