Hmmm....
Good news: this would definitely be working on 2.1.x as this code
would normally never be hit.
You can also workaround it in 2.0.x by running java2wsdl with the -
wrapperbean flag to have it generate the wrapper beans. Then the code
wouldn't be hit either. (might need to add the @RequestWrapper
annotations) (FYI: this is what you would HAVE to do if using the
JAX-WS reference implementation or metro. Per spec, that is
technically a requirement)
Using XmlJavaTypeAdapter on the param won't work with 2.0.x as that is
a feature that was added in JAX-WS 2.1. That wasn't doable in 2.0.
Basically, we have to not allow interfaces and abstract classes as
those are never actually added to the JAXB context. Only the
concrete classes are. If you try to unmarshall passing them in, you
get a "class XXX is not know to this context" error. However, it
looks like the "built ins" need to be accounted for in this check,
Calendar being the main one. Feel free to log a bug and attach a
patch.
Dan
On Jul 9, 2008, at 11:00 AM, Wojtek212 wrote:
I've found that in JAXBEncoderDecoder#unmarshall, in case of
abstract class
(like java.util.Calendar), is unmarshalled without class by JAXB
what causes
in result mentioned error: "Unmarshalling Error: unexpected element
(uri:"",
local:"from"). Expected elements are (none)".
Here is the "if" statement checking if class is abstract.
if (clazz == null || (!clazz.isPrimitive() && !
clazz.isArray()
&& !clazz.isEnum()
&& (Modifier.isAbstract(clazz.getModifiers())
|| Modifier.isInterface(clazz.getModifiers())))) {
unmarshalWithClass = false;
}
Is it correct "Modifier.isAbstract(clazz.getModifiers()"? Can someone
confirm if it is a bug and real cause of problem? If I remove
"Modifier.isAbstract(clazz.getModifiers()" everything works fine.
BTW, I'm using CFX 2.0.4.
Thanks
Wojtek
--
View this message in context:
http://www.nabble.com/Problem-with-converting-to-Calendar-tp18359438p18363266.html
Sent from the cxf-user mailing list archive at Nabble.com.
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
