Re: Possible/feasible to hook into the wsdl2code code generation?

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 
>> <[email protected] <mailto:[email protected]>> 
>> 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
>>      > <[email protected]> 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: [email protected]
>>     <mailto:[email protected]>
>>      >     <mailto:[email protected]
>>     <mailto:[email protected]>>
>>      >     For additional commands, e-mail:
>>     [email protected] 
>> <mailto:[email protected]>
>>      >     <mailto:[email protected]
>>     <mailto:[email protected]>>
>>      >
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>