The two things I suggest looking into are the WSDCode java class with ways
such as Ant / Maven to tie into it...

And the xls code for each data binding - ADB, XMLBeans, JAXB among others -
that does the "implements org.apache.axis2.data
binding.*" generation that is particular to the binding.

Since WSDL2Code supports quite a few line arguments, that'd be the place I
would try to tie into the "implements" part of the interface and class
generation from the WSDL and XSD files.

On Mon, Dec 18, 2023 at 6:31 AM Steven De Herdt
<steven.dehe...@ritacollege.be.invalid> wrote:

> Hello
>
> The project I'm working on is a client implementing dozens of WSDL
> operations/SOAP call types.  The SOAP bodies involved all follow a
> general structure, which is described in as many dozens of XSD's,
> differing only in some types several levels deep into the SOAP body.
> Error representation, bundling requests etc. are all exactly the same.
>
> When generating the service stubs, wsdl2code helpfully prepares all
> classes and types involved.  These of course also follow the same
> structure for each call type, but all those parallel classes are of
> unrelated types.  I understand they can't just be the same, but it would
> be nice for code reuse if they each implemented an interface describing
> common methods.  The names of the methods are already the same, return
> types declared in the interfaces could be these new interfaces, so I
> would just need an "implements GenericAnswerType" or some-such in the
> generated classes.
>
> Now my question: can I get something like that by plugging into Axis'
> code generation?  Or is there perhaps another way to do code
> transformation or patching from Maven?  If possible, I'd like to avoid
> 'tampering' manually with the generated sources.
>
> Thanks for any pointers you might give me.
> -Steven
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org
> For additional commands, e-mail: java-user-h...@axis.apache.org
>
>

Reply via email to