You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by robertlazarski <ro...@gmail.com> on 2024/02/06 15:44:09 UTC
Re: Possible/feasible to hook into the wsdl2code code generation?
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.deherdt@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
> > <st...@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-unsubscribe@axis.apache.org
> > <ma...@axis.apache.org>
> > For additional commands, e-mail: java-user-help@axis.apache.org
> > <ma...@axis.apache.org>
> >
>
Re: Possible/feasible to hook into the wsdl2code code generation?
Posted by robertlazarski <ro...@gmail.com>.
See AXIS2-6051 for the discussion. We cannot give accurate dates because we
are all volunteers but I can say we are all impacted by the jakarta
transition so the motivation is high.
At the moment I am on the last parts of OSGI.
Being open source, anyone is free to submit pull requests to make it go
faster.
On Tue, Feb 6, 2024 at 6:30 AM Amir Razi <am...@yahoo.com.invalid> wrote:
> Hi Robert,
>
> Thank you for the update. Any idea when the next release of Axis2 will be
> released? Also, Axis 2 is using few old versions of the dependencies like
> jettison, woodstox-core, and comms-fileupload. Will all there old version
> be updated to most recent versions that have addressed the security
> vulnerabilities?
>
> Thanks, Amir Razi
>
> On Tuesday, February 6, 2024 at 10:44:26 AM EST, robertlazarski <
> robertlazarski@gmail.com> wrote:
>
>
> 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.deherdt@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
> > <st...@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-unsubscribe@axis.apache.org
> > <ma...@axis.apache.org>
> > For additional commands, e-mail: java-user-help@axis.apache.org
> > <ma...@axis.apache.org>
> >
>
>
Re: Possible/feasible to hook into the wsdl2code code generation?
Posted by Amir Razi <am...@yahoo.com.INVALID>.
Hi Robert,
Thank you for the update. Any idea when the next release of Axis2 will be released? Also, Axis 2 is using few old versions of the dependencies like jettison, woodstox-core, and comms-fileupload. Will all there old version be updated to most recent versions that have addressed the security vulnerabilities?
Thanks, Amir Razi
On Tuesday, February 6, 2024 at 10:44:26 AM EST, robertlazarski <ro...@gmail.com> wrote:
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 <st...@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
> <st...@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-unsubscribe@axis.apache.org
> <ma...@axis.apache.org>
> For additional commands, e-mail: java-user-help@axis.apache.org
> <ma...@axis.apache.org>
>
Re: Possible/feasible to hook into the wsdl2code code generation?
Posted by Steven De Herdt <st...@ritacollege.be.INVALID>.
So, meanwhile I implemented what I needed for 1.7.9, and made a pull
request to hopefully get it in the main project. PR:
https://github.com/apache/axis-axis2-java-core/pull/589
On the off chance that anybody else in this world needs
[sorry for the SEO talk:]
Axis Axis2 Java with Rampart and also the full flexibility of xsdconfig
for the XMLBeans databinding, like the ExtensionInterfacesFeature: find
a forked v1.7.9 at
https://codeberg.org/ritacollege/axis-axis2-java-core-xsdconfig. Using
this requires some Maven hacks (warning: ain't pretty), you can find
instructions in the file GEHACK-ten-behoeve-van-Discimusagent.noot
(warning: it's in Dutch).
I'm available for questions if need be, but when Rampart gets an update
I'll be happy to retire this dreadful kludge. :)
-S
Op 9/02/2024 om 17:03 schreef Steven De Herdt:
> Thanks for taking the time for my question, that's really nice of you.
> Not every free and open source project works like that...
>
> In the mean time, it dawned on me that the prettier solution is indeed
> to just make it work upstream (in Axis2) rather than dragging along a
> hacked-together custom ball of code for the foreseeable future. After
> some tinkering I already have something working that handles a few of
> the xsdconfig options, but not yet those that need access to class
> definitions -- I still need to enable passing some kind of classpath.
>
> My main idea here is that there is already code to parse xsdconfig files
> -- in XMLBeans itself. So I copied some code from
> org.apache.axis2.xmlbeans.SchemaCompiler#loadTypeSystem and let XMLBeans
> do the heavy lifting of turning a file into a BindingConfig. If there
> would be no further options handled by Axis2BindingConfig, that would be
> enough. Now IIUC, the class XSDConfig is a kind of parallel
> implementation to XMLBeans' BindingConfigImpl, and the options there
> take precedence over Axis' own options. Is there a specific reason to
> do the xsdconfig parsing in axis2-xmlbeans? I would propose to replace
> Axis' XSDConfig with XMLBeans' BindingConfigImpl, so we get all its
> features "for free". Good idea?
>
> For the moment I'm working with Axis2 version 1.7.9, because we use
> Rampart internally. So I've been working with an even older XMLBeans.
> :) If I'm not mistaken it wouldn't be any problem to port to 1.8.x.
>
> So, I'll try to make a pull request. Some questions:
> - How much time do I have?
> - Should I include some testing? I see there is test code for
> axis2-xmlbeans, but I have only very little experience with testing.
> - Should the documentation changes go into the same pull request?
> - Building the docs is just `mvn site` right? Anything I need to watch
> out for?
>
> Kind regards
> -S
>
>
> Op 6/02/2024 om 16:44 schreef robertlazarski:
>> 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.deherdt@ritacollege.be <ma...@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
>> > <st...@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-unsubscribe@axis.apache.org
>> <ma...@axis.apache.org>
>> > <mailto:java-user-unsubscribe@axis.apache.org
>> <ma...@axis.apache.org>>
>> > For additional commands, e-mail:
>> java-user-help@axis.apache.org
>> <ma...@axis.apache.org>
>> > <mailto:java-user-help@axis.apache.org
>> <ma...@axis.apache.org>>
>> >
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-user-help@axis.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
For additional commands, e-mail: java-user-help@axis.apache.org
Re: Possible/feasible to hook into the wsdl2code code generation?
Posted by Steven De Herdt <st...@ritacollege.be.INVALID>.
Thanks for taking the time for my question, that's really nice of you.
Not every free and open source project works like that...
In the mean time, it dawned on me that the prettier solution is indeed
to just make it work upstream (in Axis2) rather than dragging along a
hacked-together custom ball of code for the foreseeable future. After
some tinkering I already have something working that handles a few of
the xsdconfig options, but not yet those that need access to class
definitions -- I still need to enable passing some kind of classpath.
My main idea here is that there is already code to parse xsdconfig files
-- in XMLBeans itself. So I copied some code from
org.apache.axis2.xmlbeans.SchemaCompiler#loadTypeSystem and let XMLBeans
do the heavy lifting of turning a file into a BindingConfig. If there
would be no further options handled by Axis2BindingConfig, that would be
enough. Now IIUC, the class XSDConfig is a kind of parallel
implementation to XMLBeans' BindingConfigImpl, and the options there
take precedence over Axis' own options. Is there a specific reason to
do the xsdconfig parsing in axis2-xmlbeans? I would propose to replace
Axis' XSDConfig with XMLBeans' BindingConfigImpl, so we get all its
features "for free". Good idea?
For the moment I'm working with Axis2 version 1.7.9, because we use
Rampart internally. So I've been working with an even older XMLBeans.
:) If I'm not mistaken it wouldn't be any problem to port to 1.8.x.
So, I'll try to make a pull request. Some questions:
- How much time do I have?
- Should I include some testing? I see there is test code for
axis2-xmlbeans, but I have only very little experience with testing.
- Should the documentation changes go into the same pull request?
- Building the docs is just `mvn site` right? Anything I need to watch
out for?
Kind regards
-S
Op 6/02/2024 om 16:44 schreef robertlazarski:
> 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.deherdt@ritacollege.be <ma...@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
> > <st...@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-unsubscribe@axis.apache.org
> <ma...@axis.apache.org>
> > <mailto:java-user-unsubscribe@axis.apache.org
> <ma...@axis.apache.org>>
> > For additional commands, e-mail:
> java-user-help@axis.apache.org <ma...@axis.apache.org>
> > <mailto:java-user-help@axis.apache.org
> <ma...@axis.apache.org>>
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
For additional commands, e-mail: java-user-help@axis.apache.org