Thanks Andrew. Yes, I believe in contract first development as well. Since I'm annotating an existing application I already get a cxf published wsdl to begin with, so I have no control over the stubs which are generated unless I make modification in the wsdl.
The problem is like this - the Service and ServiceImpl class which I have annotated using @WebService and @WebParam ONLY produce wsdl elements for either - 1. The class name 2. Method name 3. Method parameter types 4. Method return types In my case, method return type is an abstract class, wherein the actual object returned is of its subclasses. Problem 1: This subclass-es is missing in wsdl Problem 2: The method return type class has become EMPTY. All method definitions inside the original abstract class are gone! I dont know if I'm missing something here or is it a bug or its intended design. Hope that explanation was clear without me printing out the actual classes involved here. Chris --- On Wed, 6/24/09, Andrew Clegg <[email protected]> wrote: From: Andrew Clegg <[email protected]> Subject: Re: CXF - WSDL : Newbie question To: [email protected], [email protected] Date: Wednesday, June 24, 2009, 8:42 AM 2009/6/24 <[email protected]>: > Hello group! > > I am new to using CXF and have run into initial hiccups. Using JAX-WS styled > notations I have deployed my services on tomcat in testing env. > For consumption, I generated local stubs using the published wsdl. The > problem is that not all classes are getting generated and some of them are > half baked. What exactly are the problems? People here can probably help you iron them out. > What I'd like to ask group here is that - is it a common/professional > practice to alter your wsdl manually according to your needs? Or do you make > changes elsewhere (in the java stubs themselves)? I avoid Java-first for various pretty good reasons [1] but I would imagine issues in the generated code suggest issues in the WSDL which in turn suggest issues in the annotations. It's generally bad practice to alter any generated code isn't it? It puts a manual step in your build process which will recur whenever you change the original Java. Andrew. [1] http://static.springframework.org/spring-ws/sites/1.5/reference/html/why-contract-first.html -- :: http://biotext.org.uk/ ::
