You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Glen Daniels (JIRA)" <ji...@apache.org> on 2008/09/08 01:48:44 UTC
[jira] Created: (AXIS2-4018) We must be able to separate interface
from Stub implementation when generating code
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: Axis 2.0 (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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-4018) We must be able to separate
interface from Stub implementation when generating code
Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629101#action_12629101 ]
Amila Chinthaka Suriarachchi commented on AXIS2-4018:
-----------------------------------------------------
you can generate a stub interfaces with -u option. And skelton interfaces with -ssi option.
but generally this has limitations if one binding has soap headers and one not. or if one binding uses different message part from another. IMO these are rear cases and those case may cause problems for your suggestion as well.
Then the missing part is the factory class. I don't have a clear idea about how people use it. Some times people may implement this kind of factory themselves depending on the design they use.
So I think the better idea is to discuss this in user/dev list and add this feature if people find it more useful.
thanks,
Amila.
> 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: Axis 2.0 (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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org