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> 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 > . 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> > > >
