I finally found some time to look more at your question.
Also keep in mind that Axis2 uses an older version 3.x of XMLBeans, as
the project was retired then a few years later brought back to life
because Apache POI uses it. 5.2.0 was released recently.
Anyways, I am not familiar with the Extension Interfaces Feature yet I
suggest just adding it then to Axis2 as a new feature if you are so
inclined as I doubt it is hard to do. At a glance, early in the
XMLBeans 5.x series that feature had problems but seems to be fixed now.
If you could suggest how we could improve the docs here please send a
pull request to our apache axis2 github repo.
I am trying hard at the moment to wrap up the next Axis2 release soon
and can only say right now that I can get any changes you supply via
pull requests merged into our repo. Anything beyond that which
requires help, please create a Jira.
On Sun, Jan 28, 2024 at 6:56 AM Steven De Herdt
<steven.dehe...@ritacollege.be <mailto:steven.dehe...@ritacollege.be>>
wrote:
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 <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
<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>
> <mailto: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>
> <mailto:java-user-h...@axis.apache.org
<mailto:java-user-h...@axis.apache.org>>
>