Don't we already have something like this that attempts to use the BeanSerializer/Deserializer when there is no mapping? I know Glen put this functionality in under a switch, which is turned off. It probably isn't the same thing as you are doing, but can it be used instead to accomplish the same thing?
Also, I don't have a sense for what this new stuff does, not how it affects the current system. At a bare minimum, it would need to be documented, probably with at least one example of how to use it, so perhaps if you wrote that up and sent it to the list that would help people evaluate this change. In short, a weak -1 which can easily change to a +1 if I see more information (documentation). -- Tom Jordahl Macromedia Server Development -----Original Message----- From: Thomas Sandholm [mailto:[EMAIL PROTECTED] Sent: Monday, February 24, 2003 6:04 PM To: [EMAIL PROTECTED] 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
