The thing that is there does something along the lines of:
if (doAutoTypes &&
Constants.NS_URI_JAVA.equals(xmlType.getNamespaceURI())) {
try {
javaType = ClassUtils.forName(xmlType.getLocalPart());
} catch (ClassNotFoundException e) {
return null;
}
return new BeanDeserializerFactory(javaType, xmlType);
}What I am doing is to look into the actual destination class to see if it has meta data about what deserializer to be used. This has been tested to work well for both enum types and beans. Another major difference is that I am not doing my lookups until all other lookups have failed, and hence it is fully backwards compatible. So instead of returning an error saying "deserializer not found for class xxx" it tries to reflect class xxx before returning the error. (it would long term be nicer if instead of reflection we could use a common interface for those types containing serializer and typedesc meta data.)
Another thing added in my patch is that when I try to deserialize an xsd:any I can pass in a java class containing the metadata. So I would do something like:
MessageElement messageElement = myAny.get_any()[0];
MyObject obj = (MyObject) messageElement.getObjectValue(MyObject.class);
This is btw very similar to how it works in .NET.
I am ok with putting this into a separate branch not to disrupt the 1.1 release. There is however one tiny bug that I would like to commit a patch for. The BeanDeserializer never returns a fault when a deserializer is not found just a default deserializer, the code has a comment about the terra test case being the reason for this hack. I got the Terra test case to work without this hack (which causes a lot of strange error messages) when fixing a null pointer exception in the SimpleDeserializer implementation.
BTW for a full example of how to use this stuff the best thing would be to look at the test case I am checking into the branch, which is a modification of the existing wsdl/extensibility test case.
Cheers, Thomas
At 09:37 AM 2/25/2003 -0500, Tom Jordahl wrote:
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
Thomas Sandholm <[EMAIL PROTECTED]> The Globus Project(tm) <http://www.globus.org> Ph: 630-252-1682, Fax: 630-252-1997 Argonne National Laboratory
