axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Fremantle (JIRA)" <>
Subject [jira] Commented: (AXIS2-2831) Codegen creating too many stubs most of the time
Date Thu, 21 Jun 2007 10:46:26 GMT


Paul Fremantle commented on AXIS2-2831:

Glen: If there are multiple SOAP 12 ports then I would generate a stub for each of them. 

Tom: I think it is broken. I don't think its applicable to compare with Axis1, because we
have a different strategy for databinding with Axis2, and that is where the issue 3 comes.

Amila: I don't agree with your premise that the main point of wsdl2java is to generate code
for the whole WSDL. Where is that stated? When did we decide that? My view is that the whole
point of WSDL2Java is to generate A client or A service. I don't see why anyone would need
3 different clients to the same service?

And I don't think you can talk about preserving backwards compatibility. You broke all my
1.1.1 code when you changed this. If you had kept generating a single stub (PurchaseStub)
named after the service then my old code would still work. That is completely bogus to claim
that just because you broke it between 1.1.1 it now has to be fixed the way it is in 1.2 forever

I really care about this. The way it is now makes it hard for beginners to use our client
generation code, which is the first thing they will try. So you are making it less likely
users will stick with Axis2.


> Codegen creating too many stubs most of the time
> ------------------------------------------------
>                 Key: AXIS2-2831
>                 URL:
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Improvement
>          Components: codegen
>    Affects Versions: 1.2
>            Reporter: Paul Fremantle
>            Assignee: Amila Chinthaka Suriarachchi
>            Priority: Blocker
>             Fix For: 1.3
> When we moved from 1.1.1 to 1.2, we changed the codegen to create a different stub object
per WSDL port. 
> This had the following three consequences:
> 1) The Stub name is more complex and frankly ugly 
> instead of PurchaseStub I get PurchasePurchaseSOAP12Port_httpStub 
> 2) There are more classes lying around (for a standard Axis2 service it now generates
6 classes instead of 2). It also means there are now warnings raised on the command line where
classes are shared between stubs.
> Jun 20, 2007 3:40:03 PM org.apache.axis2.wsdl.codegen.writer.ClassWriter createOutFile
> INFO: The .\src\sample\axisversion\ file cannot be overwritten.
> Jun 20, 2007 3:40:03 PM org.apache.axis2.wsdl.codegen.writer.ClassWriter createOutFile
> INFO: The .\src\sample\axisversion\ file cannot be overwritten.
> 3) Its really hard to find the correct databinding class for the parameters of the stub.
There are now multiple copies of each databinding class (as inner classes inside the different
stubs). When I do code completion in Eclipse its pretty hard to figure out the right class,
and I guess for a beginner maybe impossible.
> Now I realize that there are some wierd WSDLs out there, and maybe just maybe 1% of the
time we need to do this. But in 99% of cases, and 100% of cases where Axis2 created the WSDL,
this is unnecessary.
> I know what is gonna be said: I can use -pn Portname to explicitly choose one port. But
that requires me to (1) be able to read WSDL correctly and (2) actually know about this option.
Neither of those are appropriate for a beginner and also even for an advanced user they make
life difficult.
> My proposal is simple - choose one port (how about the SOAP12 if it exists, then the
SOAP11 one, then the HTTP one) and only generate code for that. Add a switch to generate all
ports if required. I can't see why I need more than one working stub. If SOAP12 is working
why do I care about having a SOAP11 stub lying around. 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message