[jira] Resolved: (AXIS2-4018) We must be able to separate interface from Stub implementation when generating code

["Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>]

     [ 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org