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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
Sent: Tuesday, August 02, 2005 9:14 PM
To: [email protected]
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
