What you describe is exceedingly bad practice.
Much better to take the approach that thrift does where the generated code
is never touched by the developer. The thrift code generator generates
portable marshaling code and an interface. The programmer implements the
interface and injects their implementation and a transport into a server at
server construction time. Clients inject a transport into a client
interface.
This separates generated code from hand-written code and is a very effective
approach. Changes to the thrift IDL are easily propagated into Java (or any
other supported language). Changes to the implementation are preserved with
no fancy footwork required.
With the approach you describe it is exceedingly difficult to guarantee that
the developer's code is preserved.
On Mon, Jul 20, 2009 at 12:09 PM, Jason Weinstein <
jasonweinstein@hotmail.com> wrote:
> On the server side you generate a set of boilerplate implementation classes
> which include a set of stubs for the web service interfaces. The developer
> then codes in the implementation for each method. Quite often changes are
> made to the wsdl and the files need to be regenerated. In this case it would
> be nice to maintain the existing developers code.
>
--
Ted Dunning, CTO
DeepDyve