This is great, but I was actually referring to the latest patch to add the BeanDeserailizer.DESERIALIZE_ANY to the MessageContext. If there is a place you can patch the existing HTML documentation to let developers know that they can configure this behavior.
But too much info is better than too little! :-) Actually, this bring up a good question: Is there a place we document might be set/found in the MessageContext property list? -- Tom Jordahl Macromedia -----Original Message----- From: Thomas Sandholm [mailto:[EMAIL PROTECTED]] Sent: Friday, May 10, 2002 12:24 PM To: [EMAIL PROTECTED]; '[EMAIL PROTECTED]' Subject: RE: minor patches to xsd:any support OK sure, I had a discussion with Glen on IRC about implementing it in a cleaner way too but here is the current implementation and future implementation thoughts as I see them: Note that this feature can only be used in literal mode. Current Implementation: ---------------------------------- 1. xsd:any namespace="##any" elements are detected by WSDL2Java and an any property of type Object is added to the Bean. The user can get and set this property like any other bean property, i.e. using setAny() and getAny() accessors. 2. one thing that differs this any from the xsd:anyType is that the property name ('any') will be suppressed and not serialized across the wire as an element tag, so that the XML blob does not have to be wrapped. 3. 2) means that the BeanDeserializer has to be able to recognize arbitrary elements sent into it and put them into the any property 4. If a deserializer is registered for the fully qualified element qname that the BeanDeserializer detects it can try to deserialize the element into the correct java type. If no deserializer was found the content will be deserialized as a dom Element. 5.The element qname to java type mapping is disabled by default (and the dom Element deserialization will always happen) but it can be enabled by setting the BeanDeserailizer.DESERIALIZE_ANY property in the MessageContext. 6. Both DOM Element objects as well as Beans generated from an arbitrary XMLSchema element definition (e.g. containing both element and attribute definitions) can be passed into an any property. Future Implementation Thoughts: ------------------------------------------------- 1. Make Beans implement an interface to flag that they expose an xsd:any property to avoid clashes with other any property values 2. Support namesppace="<namespace>" that can be queried using the interface in 1) and validated 3. Separate out the element mapping from the type mapping in a separate ElementMapping registry that can be configured like the current typeMappings in the deployment configuration 4. Provide toElement() toObject() operations to easily go between object and DOM Element representations. Note there are some roundtrip problems involved here. But a general feature like the XmlSerializer in dotnet would be useful to have. Hopefully JAXB will eventually help out here. But the trick is to integrate it with the Axis Bean model. For more details on how to use the feature and a possible use case scenario look at the wsdl/extensibility test case. /Thomas At 11:41 AM 5/10/2002 -0400, Tom Jordahl wrote: >Hi Thomas, > >Thanks for the patch. How about sending along some documentation for the >new feature? Otherwise you will be the only one to know about it! :-) > >-- >Tom Jordahl >Macromedia > > >-----Original Message----- >From: Thomas Sandholm [mailto:[EMAIL PROTECTED]] >Sent: Thursday, May 09, 2002 8:46 PM >To: [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED] >Subject: minor patches to xsd:any support > > >Just some minor patches to allow you to turn on and off xsd:any -> object >deserialization. If it is turned off a dom Element will always be >constructed. Note the extensibility test case has been updated and has to >be applied together with the src fixes. > >/Thomas Thomas Sandholm <[EMAIL PROTECTED]> The Globus Project(tm) <http://www.globus.org> Ph: 630-252-1682, Fax: 630-252-1997 Argonne National Laboratory
