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 Sanjiva Weerawarana <sa...@opensource.lk> on 2005/08/04 15:06:59 UTC

Re: [jira] Updated: (AXIS2-109) Databinding completeness in the stubs that are generated

Irrespective of the major/minor discussion, I'd like to discuss a
principle that Tom has indicated in this thread: the shape of the stub
should be independent of the data binding framework.

IMO we shouldn't do that: if its a standard-compliant databinding
framework (e.g., a JAXB2 one or a JAX-RPC 1.x one) then of course no
matter what impl of that framework you use you should get the same shape
of a stub. However, if I use XMLBeans then I think at least the option
to get the "natural" binding generated by that framework needs to be
supported. 

So my preferred way to address this specific "bug" would be to say:
"Damn, you used the wrong databinding framework! Here, turn this option
on to engage the JAXB compliant databinder and you'll get what you want
to get." 

Of course we haven't quite plugged in a JAXB compliant databinder yet
but that's a new feature request, not a bug ;-).

Sanjiva.

On Thu, 2005-08-04 at 18:41 +0600, Srinath Perera wrote:
> Hi Tom;
> 
> I make it minor due to 2 reasons
> 
> 1) It is to be handled after the 0.95 (we say we need to fix all that
> is major for 0.95 so that the major is relative! )
> 2) I understood the bug to mean "we need a make the client stub not
> have xml beans specific things", have I misunderstood it?
> 
> Thanks
> Srinath
> 
> 
> 
> On 8/4/05, Tom Jordahl <to...@macromedia.com> wrote:
> > 
> > I really don't agree that support for wrapped services is Minor....
> > 
> > 
> > Tom Jordahl
> > Macromedia Server Development
> > 
> > -----Original Message-----
> > From: Srinath Perera (JIRA) [mailto:jira@apache.org]
> > Sent: Tuesday, August 02, 2005 9:14 PM
> > To: axis-dev@ws.apache.org
> > Subject: [jira] Updated: (AXIS2-109) Databinding completeness in the
> > stubs that are generated
> > 
> >      [ http://issues.apache.org/jira/browse/AXIS2-109?page=all ]
> > 
> > Srinath Perera updated AXIS2-109:
> > ---------------------------------
> > 
> >     Priority: Minor  (was: Major)
> > 
> > post 0.95
> > 
> > > Databinding completeness in the stubs that are generated
> > > --------------------------------------------------------
> > >
> > >          Key: AXIS2-109
> > >          URL: http://issues.apache.org/jira/browse/AXIS2-109
> > >      Project: Apache Axis 2.0 (Axis2)
> > >         Type: Improvement
> > >   Components: databinding
> > >     Reporter: Jayachandra Sekhara Rao Sunkara
> > >     Priority: Minor
> > >  Attachments: SimpleTest.wsdl
> > >
> > > We should project stub methods tha are completely agnostic of the
> > databinding mechanism utilized to generate them.
> > > FYI, I'm copy pasting the issue that was mailed to axis-dev on 28th
> > July 2005
> > > *** Transcript of the mail follows ***
> > > Hi there,
> > > I planned to test a stub based style of invocation with this wsdl
> > [attached below- SimpleTest.wsdl].
> > > Its the wsdl for a webservice which hosts a method of the signature
> > public String echoString(String inputString); I started with wsdl2java
> > to generate stubs for me. I then set out to write a test client (this
> > was lacking from wsdl2java artifacts that got generated) that would just
> > assume as if it was invoking a local method named echoString on the
> > stub. Strangely the method signature of
> > > echoString(..) in the generated stub is seen to expect an XMLBeans
> > specific EchoStringDocument kind of object as its input parameter.
> > > This makes us think that data binding is not facilitated to the user
> > fully. User shouldn't have to bore the onus of creating an
> > EchoStringDocument object and pass it as parameter to the stub method,
> > at least when he is using the stub based invocation, isn't it? Is this
> > feature on our wish list or am I missing something!?!
> > > Thank you
> > > Jayachandra
> > 
> > --
> > This message is automatically generated by JIRA.
> > -
> > If you think it was sent incorrectly contact one of the administrators:
> >    http://issues.apache.org/jira/secure/Administrators.jspa
> > -
> > For more information on JIRA, see:
> >    http://www.atlassian.com/software/jira
> > 
> >
> 



Re: [jira] Updated: (AXIS2-109) Databinding completeness in the stubs that are generated

Posted by Dennis Sosnoski <dm...@sosnoski.com>.
I agree completely that you need to pass classes compatible with the 
data binding framework for any complex objects. But based on my JibxSoap 
experiences with adding wrapped support (still in progress), I suspect 
the best way of handling this may be to build in "canned" 
serializer/deserializers for primitive types and their wrapper 
equivalents, along with String and perhaps a few other special classes. 
The data binding frameworks should only get involved at the level of 
individual parameters in a wrapped request which are themselves complex 
objects, but at that level you have to use the classes that are 
compatible with the framework.

If you applied this approach to the case being discussed you'd get the 
expected public String echoString(String inputString) method in the 
stub. This does make more work for the Axis2 code, since the wrapped 
encoding process (in the stub) needs to call the appropriate 
serialization technique for each parameter (built-in or data binding), 
and the decoding process needs to call the appropriate deserializer 
(likewise), but it gives users what I'd consider the cleanest API. If 
someone wants to use the data binding framework exclusively, they can 
just disable the unwrapping.

  - Dennis

Sanjiva Weerawarana wrote:

>Irrespective of the major/minor discussion, I'd like to discuss a
>principle that Tom has indicated in this thread: the shape of the stub
>should be independent of the data binding framework.
>
>IMO we shouldn't do that: if its a standard-compliant databinding
>framework (e.g., a JAXB2 one or a JAX-RPC 1.x one) then of course no
>matter what impl of that framework you use you should get the same shape
>of a stub. However, if I use XMLBeans then I think at least the option
>to get the "natural" binding generated by that framework needs to be
>supported. 
>
>So my preferred way to address this specific "bug" would be to say:
>"Damn, you used the wrong databinding framework! Here, turn this option
>on to engage the JAXB compliant databinder and you'll get what you want
>to get." 
>
>Of course we haven't quite plugged in a JAXB compliant databinder yet
>but that's a new feature request, not a bug ;-).
>
>Sanjiva.
>
>On Thu, 2005-08-04 at 18:41 +0600, Srinath Perera wrote:
>  
>
>>Hi Tom;
>>
>>I make it minor due to 2 reasons
>>
>>1) It is to be handled after the 0.95 (we say we need to fix all that
>>is major for 0.95 so that the major is relative! )
>>2) I understood the bug to mean "we need a make the client stub not
>>have xml beans specific things", have I misunderstood it?
>>
>>Thanks
>>Srinath
>>
>>
>>
>>On 8/4/05, Tom Jordahl <to...@macromedia.com> wrote:
>>    
>>
>>>I really don't agree that support for wrapped services is Minor....
>>>
>>>
>>>Tom Jordahl
>>>Macromedia Server Development
>>>
>>>-----Original Message-----
>>>From: Srinath Perera (JIRA) [mailto:jira@apache.org]
>>>Sent: Tuesday, August 02, 2005 9:14 PM
>>>To: axis-dev@ws.apache.org
>>>Subject: [jira] Updated: (AXIS2-109) Databinding completeness in the
>>>stubs that are generated
>>>
>>>     [ http://issues.apache.org/jira/browse/AXIS2-109?page=all ]
>>>
>>>Srinath Perera updated AXIS2-109:
>>>---------------------------------
>>>
>>>    Priority: Minor  (was: Major)
>>>
>>>post 0.95
>>>
>>>      
>>>
>>>>Databinding completeness in the stubs that are generated
>>>>--------------------------------------------------------
>>>>
>>>>         Key: AXIS2-109
>>>>         URL: http://issues.apache.org/jira/browse/AXIS2-109
>>>>     Project: Apache Axis 2.0 (Axis2)
>>>>        Type: Improvement
>>>>  Components: databinding
>>>>    Reporter: Jayachandra Sekhara Rao Sunkara
>>>>    Priority: Minor
>>>> Attachments: SimpleTest.wsdl
>>>>
>>>>We should project stub methods tha are completely agnostic of the
>>>>        
>>>>
>>>databinding mechanism utilized to generate them.
>>>      
>>>
>>>>FYI, I'm copy pasting the issue that was mailed to axis-dev on 28th
>>>>        
>>>>
>>>July 2005
>>>      
>>>
>>>>*** Transcript of the mail follows ***
>>>>Hi there,
>>>>I planned to test a stub based style of invocation with this wsdl
>>>>        
>>>>
>>>[attached below- SimpleTest.wsdl].
>>>      
>>>
>>>>Its the wsdl for a webservice which hosts a method of the signature
>>>>        
>>>>
>>>public String echoString(String inputString); I started with wsdl2java
>>>to generate stubs for me. I then set out to write a test client (this
>>>was lacking from wsdl2java artifacts that got generated) that would just
>>>assume as if it was invoking a local method named echoString on the
>>>stub. Strangely the method signature of
>>>      
>>>
>>>>echoString(..) in the generated stub is seen to expect an XMLBeans
>>>>        
>>>>
>>>specific EchoStringDocument kind of object as its input parameter.
>>>      
>>>
>>>>This makes us think that data binding is not facilitated to the user
>>>>        
>>>>
>>>fully. User shouldn't have to bore the onus of creating an
>>>EchoStringDocument object and pass it as parameter to the stub method,
>>>at least when he is using the stub based invocation, isn't it? Is this
>>>feature on our wish list or am I missing something!?!
>>>      
>>>
>>>>Thank you
>>>>Jayachandra
>>>>        
>>>>
>>>--
>>>This message is automatically generated by JIRA.
>>>-
>>>If you think it was sent incorrectly contact one of the administrators:
>>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>>-
>>>For more information on JIRA, see:
>>>   http://www.atlassian.com/software/jira
>>>
>>>
>>>      
>>>
>
>
>  
>