Hi Tomek,
I see that a number of other people have reported this same problem on
this mailing list in the past couple of weeks. The issue is not about
the XmlBeans generation but that XFire is not picking the concrete beans
classes when it is binding with wsgen during stub generation. I have a
working version with XFire 1.2RC1 and XmlBeans 2.1.0 but it seems silly
to have to use such an old release of XFire when newer ones are available.
Cheers,
Matthew
Tomek Sztelak wrote:
I can't answer your question, because i don't know much about
xmlbeans.But you can post this question on xmlbeans mailing list. You
can also try to change your pom dependency to previous xmlbeans
version.
On 4/25/07, Matthew Graham <[EMAIL PROTECTED]> wrote:
Hi,
I'm trying to find help with this for the third time since I have no
idea what the problem is:
I was previously using XFire 1.2RC1 with XmlBeans 2.1.0 and generating
server side stubs with wsgen under Maven. This gave me methods such as:
public SetNodeResponseDocument setNode(SetNodeDocument SetNode)
throws InternalFault_Exception, InvalidArgumentFault_Exception,
InvalidUriFault_Exception, NodeNotFoundFault_Exception,
PermissionDeniedFault_Exception
{
throw new UnsupportedOperationException();
}
However, with XFire 1.2.5 and XmlBeans 2.2.0, I'm getting:
public XmlObject setNode(XmlObject node)
throws InternalFaultMessage, InvalidArgumentFaultMessage,
InvalidUriFaul tMessage, NodeNotFoundFaultMessage,
PermissionDeniedFaultMessage
{
throw new UnsupportedOperationException();
}
I have generated and compiled the beans from the schema with XmlBeans
2.2.0 (scomp -out schema.jar schema.xsd) and they are definitely in the
classpath for the wsgen task.
In my server code, I have now tried casting the XmlObject to the bean
type it should be but this does not seem to work properly:
java.lang.ClassCastException:
org.apache.xmlbeans.impl.values.XmlAnyTypeImpl
at
edu.caltech.nvo.vospace.VOSpaceServiceImpl.listNodes(VOSpaceServiceImpl.java:189)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.xfire.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:54)
at
org.codehaus.xfire.service.invoker.ObjectInvoker.invoke(ObjectInvoker.java:45)
So why is the newer version of XFire just giving me a generic XmlObject
instead of the
specific bean type?
Cheers,
Matthew
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
