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
