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 Steven De Herdt <st...@ritacollege.be.INVALID> on 2024/04/11 20:52:53 UTC
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
>> <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