How I solve the problem is
I generate all the classes and redirect to my classes at the appropriate
points using sed 
 
For the web service classes I have my own implementation that implements
the interface and I sed the generated skeleton class replacing the
reference to the generated impl class with a reference to my class. Here
is the one line of sed:
        sed
"s/$packageOfWebServiceClasses."$serviceName"SoapBindingImpl/$myImpl/g"


For the data classes I subclass the generated classes. To  ensure my
classes are constructed 
I modify the Stud class. Specifically I replace references to the
generated data classes where they are registered for (de)serialization
with references to my data classes. The sed for this is:
        sed "s/cls = $generatedClass\.class/cls = $myclass.class/g"


So I always use all the generated code except for the trivial service
Impl class and if there is a mismatch between my classes and the wsdl it
turns up in as an understandable compile error

WSDL2Java could support this if anyone had any time (I dont so why
should any one else) by for example  allowing the specification of and
alternative service implementation classes and the specification of
alternative implementations of the data classes (which must be
subclasses though)


I am moving away from extending the data classes to wrapping them. This
makes extending class non leaf classes possible and everything a bit
clearer. It will just mean that I have to do the wrapping and write the
wrapping classes which may be tedious.


Another idea ,which may have been mooted earlier, would be an
implementation of the (de)serializers that did not rely on metadata eg
org.apache.axis.description.FieldDesc in the data classes but built this
up at runtime by refection (it wouldn't be too slow because you would
only have to do it once). Then WSDL2Java could optionally generate
interfaces rather than implementations of the data classes. The hand
coded data classes could just implement these interfaces. [ I not sure
what to do with the super equals and super hashcode methods but I think
the idea still flies]


Chad

Reply via email to