At this point, while this sounds cool, I'm fairly against introducing any
new functionality to the code for 1.1. I understand that this
functionality is critical to what you're looking to do, but we had
established a while back that we were going to focus strictly on critical
bugs for the 1.1 release and that new functions would be looked at for
1.2. However, I'm going to vote +0 on this for now and wait to see what
the other committers have to say.
- James Snell
IBM Emerging Technologies
[EMAIL PROTECTED]
(559) 587-1233 (office)
(700) 544-9035 (t/l)
Programming Web Services With SOAP
O'Reilly & Associates, ISBN 0596000952
Have I not commanded you? Be strong and courageous.
Do not be terrified, do not be discouraged, for the Lord your
God will be with you whereever you go. - Joshua 1:9
Thomas Sandholm <[EMAIL PROTECTED]>
02/24/2003 03:03 PM
Please respond to axis-dev
To
[EMAIL PROTECTED]
cc
bcc
Subject
VOTE Deserialization without TypeMapping
Sorry for pushing it, maybe I should have been more clear about this. It
is
a critical issue for my project so I would like to get a vote on whether
you think this should be in the 1.1 release scheduled for March 10th.
If not I will put it into a branch and merge it post 1.1. So +1 would mean
in 1.1 release and -1 would mean post 1.1 merge of branch.
Thanks,
Thomas
At 03:18 PM 2/23/2003 -0600, Thomas Sandholm wrote:
>Hi,
>
>I have been playing around with deserialization without the need for type
>mappings in the deployment descriptors (useful in dynamic doc/lit and
>##any scenarios) by using WSDL2Java generated metadata. I have put in
>hooks to use the getDeserializer method of a class if no TypeMapping is
>found in the TypeMappingRegistry. Because it is so close to a release I'd
>like to get the opinion of the committers whether you think it's a good
>idea to commit this into the cvs trunk/head or put it in a separate
branch?
>
>Here is what I have done:
>-Added callouts to get deserializer from destination class from
RPCHandler
>and BeanDeserializer in case none was found using the normal lookup
>-Added following methods to DeserailizationContext interface:
>public Deserializer getDeserializerForClass(Class cls);
>public Class getDestinationClass();
>public void setDestinationClass(Class cls);
>-Added following methods to axis MessageElement
>public Object getObjectValue(Class cls);
>-Changed Enum Type generator to generate deserialization meta data
>-Added hooks to ArrayDeserializer to deserialize based on destination
>class if no typemapping was found
>
>I have run it through all the tests and I have modified the
>wsdl/extensibiliity test case to exercise the new functionality.
>Note this approach does not work so well with polymorphic values which is
>why the xsi:type etc lookups are always performed first.
>
>So, branch or trunk or explain more?
>
>Cheers,
> Thomas
>
>
>
>
>
>Thomas Sandholm <[EMAIL PROTECTED]>
>The Globus Project(tm) <http://www.globus.org>
>Ph: 630-252-1682, Fax: 630-252-1997
>Argonne National Laboratory
Thomas Sandholm <[EMAIL PROTECTED]>
The Globus Project(tm) <http://www.globus.org>
Ph: 630-252-1682, Fax: 630-252-1997
Argonne National Laboratory
