[
https://issues.apache.org/jira/browse/AXIS2-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amila Chinthaka Suriarachchi resolved AXIS2-4018.
-------------------------------------------------
Resolution: Fixed
If the binding does not change then users can use one generated stub interface
by passing options to send soap11 or soap12 or http binding level messages.
> We must be able to separate interface from Stub implementation when
> generating code
> -----------------------------------------------------------------------------------
>
> Key: AXIS2-4018
> URL: https://issues.apache.org/jira/browse/AXIS2-4018
> Project: Axis2
> Issue Type: Bug
> Components: adb, codegen
> Reporter: Glen Daniels
>
> I was just running through some slides and tests re: Axis2 codegen when I
> suddenly realized that we don't currently have the ability to separate out a
> client-side abstract interface for the abstract part of a WSDL when doing
> wsdl2java.
> I searched JIRA and, unbelievably, didn't see anything quite like this, but
> please add to this if you know of another open issue on this topic.
> This is doubleplus ungood, folks. The whole point of "loose coupling" via
> bindings in WSDL is precisely so I can program to the abstract interface and
> not care what the actual implementation is. I want that same flexibility to
> reflect itself in the generated Java. Right now, if you tell wsdl2java to
> generate code for all ports, we get multiple Stubs which are all completely
> separate and do not share a common interface!! :(
> We need to discuss exactly how this should look, and then switch to doing it
> this way BY DEFAULT (IMO).
> My proposal would be - "wsdl2java foo.wsdl" (assuming that contains a single
> portType and N bindings/ports) should generate three things:
> 1) A Java interface Foo reflecting the portType in the abstract, which all
> concrete Stubs implement
> 2) A FooFactory for obtaining an implementation of said interface. The
> factory has methods like:
> public Foo getFoo();
> public Foo getFoo(String address);
> public Foo getFooByEndpointName(String endpintName);
> public Foo getFoo(Context ctx);
> The context parameter is basically a Map which contains arbitrary info to
> help the factory decide what to do.
> 3) The actual concrete FooSOAP11Stub (for instance).
> The factory needs a plugin API so that new stubs can be dynamically added,
> and this API is how the concrete stubs hook themselves into the creation
> logic.
> To be clear - the goal is to be able to generate a SINGLE interface for a
> WSDL portType/interface that client code can be written to use, independent
> of binding type, policies, etc. After I've already generated some stubs, I
> should be able to generate code for a brand new WSDL containing a new binding
> of the same interface, and (assuming I run wsdl2java in the same directory I
> used the first time) it should end up just generating a new concrete stub
> class and hooking that in to the existing Factory class so it can be accessed.
> Thoughts?
--
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: [email protected]
For additional commands, e-mail: [email protected]
