Thanks Dan. For #4, I'm just wondering how things may work in a distributed dev environment. For example, TeamA could be creating/managing the wsdls, and TeamB could be responsible for the java implementation. If TeamA makes a small change to the parameter types in a wsdl without TeamB being aware of it, and no errors actually occur, no one will know that a problem still exists. Since the Muse layer is the central point for mapping and translating xml requests and responses based on the wsdl, it would be ideal if it could also do some data validation. Is there a way to extend Muse to do such data validation, or is this something that needs to be built in addition to Muse? -Vinh
-----Original Message----- From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] Sent: Friday, October 27, 2006 1:37 PM To: [email protected] Subject: Re: message types not checked? 3. You do need to create the custom serializers for custom types. We don't have a serializer generator for java bean types, and even if we did, not all classes are java beans. The XStreamSerializer class is a good way to serialize complex types w/o generating a lot of plumbing code. The JavaDoc for that class explains how to extend it and plug it into muse.xml to serialize/deserialize your types. The alternative is using some other data binding framework (or custom DOM code) to write the serializers. And yes, for 100 unique complex types, you would need 100 custom serializers. Whether you have just the XSD, just the Java, or both, it's not really possible for wsdl2java to 'just know' how an XSD type maps to a Java type. This is true no matter how many types there are. 4. wsdl2java should be generating method signatures that match the types you have in your WSDL - this relates to #1, and once we've fixed whatever issue there is in your WSDL, you will have a method that returns 'int'. If you then manually change the return type to String, it will still work, but we can only do so much to protect you from yourself. ;) Dan Andrew Eberbach/Durham/[EMAIL PROTECTED] wrote on 10/27/2006 03:58:57 PM: > Hi Vinh, > > I've put comments below: <ame/> > > Thanks, > Andrew > > Andrew Eberbach > Autonomic Computing > (919) 254-2645 > T/L: 444-2645 > [EMAIL PROTECTED] > > > > "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> > 10/27/2006 03:47 PM > Please respond to > [email protected] > > > To > <[email protected]> > cc > "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> > Subject > message types not checked? > > > > > > > Hello all, > I have a few questions: > > 1) The wsdl2java script creates the java "stub" classes and an operation > method in each class, but the method is incomplete. No parameters are > generated in the method signature, even if the wsdl indicates that a > parameter is passed to the operation. Is this the intended design, or > is it up to the developer to fill in the correct parameters in the java > code? > > <ame>There should definitely be parameters in the methods. Can you give an > > example of a wsdl that generates methods with no parameters when the wsdl > specifies parameters?</ame> > > 2) If I create a custom element type (i.e. not a standard type like > integer, String, boolean) in the wsdl, the wsdl2java script generates an > operation method with a return type of org.w3c.dom.Element. Is this the > design we should be working with, or is it up to the developer to modify > this to return the correct custom type? For example, if I created a > type called Box, does the operation method need to return a Box type? > > <ame>There's a way to get custom serializers defined in muse.xml, but I > didn't > have time to integrate this into wsdl2java. You can manually change it (if > > you're a developer) in the generated code.</ame> > > 3) If our operations return a custom type (i.e. not a standard type like > integer, String, boolean), am I correct in saying that the we must > implement our own serializers for each custom type? So if we had 100 > custom types, does each type need its own serializer, and the > serializers need to be specified in the wsdl descriptor? Or, am I > looking at this wrong? > > <ame>Dan this is xstream territory...</ame> > > 4) Muse is not properly checking the element types defined in the wsdl. > For example, the following defines a response element of type integer: > <xsd:schema > elementFormDefault="qualified" > targetNamespace="http://cisco.com/muse/demo/cap/box > <http://cisco.com/muse/demo/cap/box> "> > <xsd:element name="BoxOperation" type="xsd:string" /> > <xsd:element name="BoxOperationResponse" type="xsd:integer" > /> > </xsd:schema> > > But, in my code, I can define my operation to return an element of type > String: > > public class BoxCapability extends AbstractCapability implements > IBoxCapability > { > public String boxOperation(String param1) throws Exception > { > return "hello friend"; > } > } > > When I run my test client, I can see the string output in the console, > and no error is thrown to indicate that my java operation is returning a > type that does not match what is defined in the wsdl. If this is the > intended behavior, this will definitely open a can of errors at some > point, and it will be very difficult to trace. > > <ame>This is also Dan's domain...</ame> > > Any help is appreciated, thanks! > -Vinh > > --------------------------------------------------------------------- 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]
