Hmmmm. Even if Muse had such validation, if TeamA made the change without communicating it beforehand to TeamB, it would break the build and TeamB would have to fix it. I think that making TeamB rely solely on a broken build or regression test is sub-optimal and frustrating. So, while this validation would be nice, I think the root cause of your problem is that TeamA is allowed to commit changes to core pieces of your application without any review by the rest of the development team.
Would you like to try and add this validation as a contribution? That would be very helpful - open a JIRA item and we will track it; if you can add the validation w/o breaking the MessageHandler interface, we can add it to 2.2. The code that would do this validation would be in the SimpleResourceDescriptor and ReflectionMessageHandler classes. Dan "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 10/27/2006 05:36:36 PM: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
