Hi Robert
Thanks for your answer. It took me a while to examine my options here,
it's a lot more complicated than the acronym "SOAP" suggests...
At first I was looking through the code that does code generation. It
seemed rather involved to fork it and make it do exactly what I wanted.
Then, following your hint about WSDL2Code's command line arguments, I
discovered '-xsdconfig'. I am already using the XMLBeans bindings, and
it turns out there's a feature in there that's exactly what I'm looking
for:
https://cwiki.apache.org/confluence/display/XMLBEANS/ExtensionInterfacesFeature
. Nice, and I could get it to work with XMLBeans' scomp utility. I
managed to pass the location of the xsdconfig file through my pom.xml --
not clearly documented, see here:
https://marc.info/?l=axis-user&m=120177766308116. Apparently though,
the code in axis2-xmlbeans to parse the xsdconfig does not support this
Extension Interfaces Feature. (I also noticed that changing a generated
class name (qname element) fails with the xsdconfig through Maven, while
the same xsdconfig through scomp works.)
So back to square one I guess. Would it be easiest to just fork a
codegen package and make a quick and dirty hack in the code or a stylesheet?
Greetings
-Steven
Op 19/12/2023 om 21:35 schreef robertlazarski:
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
<mailto:java-user-unsubscr...@axis.apache.org>
For additional commands, e-mail: java-user-h...@axis.apache.org
<mailto:java-user-h...@axis.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org
For additional commands, e-mail: java-user-h...@axis.apache.org
