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


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org
For additional commands, e-mail: 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

Reply via email to