axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amila Chinthaka Suriarachchi (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (AXIS2-4018) We must be able to separate interface from Stub implementation when generating code
Date Sat, 25 Dec 2010 04:44:45 GMT

     [ 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


Mime
View raw message